similar to: [RFC][PATCH 2/5] timekeeping: Fix potential lost pv notification of time change

In 780427f0e11 (Indicate that clock was set in the pvclock gtod notifier), logic was added to pass a CLOCK_WAS_SET notification to the pvclock notifier chain. While that patch added a action flag returned from accumulate_nsecs_to_secs(), it only uses the returned value in one location, and not in the logarithmic accumulation. This means if a leap second triggered during the logarithmic

From: David Vrabel <david.vrabel@citrix.com> The high resolution timer code gets notified of step changes to the system time with clock_was_set() or clock_was_set_delayed() calls. If other parts of the kernel require similar notification there is no clear place to hook into. Add a clock_was_set atomic notifier chain (clock_was_set_notifier_list) and call this in place of clock_was_set().

From: David Vrabel <david.vrabel@citrix.com> Instead of passing multiple bools to timekeeping_updated(), define flags and use a single ''action'' parameter. It is then more obvious what each timekeeping_update() call does. Signed-off-by: David Vrabel <david.vrabel@citrix.com> --- kernel/time/timekeeping.c | 21 ++++++++++++--------- 1 files changed, 12

With the storage array in place it's now trivial to support CLOCK_TAI in the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use of the fact that: - CLOCK ids are set in stone - CLOCK_THREAD_CPUTIME is never going to be supported in the VDSO so the array slot 3 is unused - CLOCK_TAI is id 11 which results in 3 when masked with 0x3 Add the mask to the basetime array

> On Sep 14, 2018, at 5:50 AM, Thomas Gleixner <tglx at linutronix.de> wrote: > > With the storage array in place it's now trivial to support CLOCK_TAI in > the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use > of the fact that: > > - CLOCK ids are set in stone > - CLOCK_THREAD_CPUTIME is never going to be supported in the VDSO so >

> On Sep 14, 2018, at 5:50 AM, Thomas Gleixner <tglx at linutronix.de> wrote: > > With the storage array in place it's now trivial to support CLOCK_TAI in > the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use > of the fact that: > > - CLOCK ids are set in stone > - CLOCK_THREAD_CPUTIME is never going to be supported in the VDSO so >

Hi Ian/Stefano: I changed over to the PV clock for hybrid liked we talked at the hackathon. I still have the hang in update_wall_time() after dom0 switches to xen as clocksource. The source of hang seems to be in xen stime_local_stamp in cpu_time that suddenly jumps to a large 64bit value. I''ve been chasing to figure where that happens, and why for the hybrid and not PV. It appears the

Hi! Short time ago our Samba-Server crashed during normal use with low load. (Ping was working, but no login was possible (didn't ask for password on the terminal)). Perhaps it is a bug, or perhaps it is a problem with my machine and you can help me. I am running: SuSE Linux 6.4 Samba Version 2.0.6 (smbd) Kernel: 2.2.14 (original SuSE-Kernel) Some Logfiles: /var/log/warn ... Aug 16

Optimize opus encode (float only) usecase using ARM NE10 library. Mainly effects opus_fft and ctl_mdct_forward and related functions. This optimization can be used for ARM CPUs that have NEON VFP unit. This patch only enables optimizations for ARMv7. Official ARM NE10 library page available at http://projectne10.github.io/Ne10/ To enable this optimization, use --enable-intrinsics

Optimize opus encode (float only) usecase using ARM NE10 library. Mainly effects opus_fft and ctl_mdct_forward and related functions. This optimization can be used for ARM CPUs that have NEON VFP unit. This patch only enables optimizations for ARMv7. Official ARM NE10 library page available at http://projectne10.github.io/Ne10/ To enable this optimization, use --enable-intrinsics

Optimize opus encode (float only) usecase using ARM NE10 library. Mainly effects opus_fft and ctl_mdct_forward and related functions. This optimization can be used for ARM CPUs that have NEON VFP unit. This patch only enables optimizations for ARMv7. Official ARM NE10 library page available at http://projectne10.github.io/Ne10/ To enable this optimization, use --enable-intrinsics

People at vmware have provided patches for RHEL 5 that aim to fix timekeeping issues in vmware guests. https://bugzilla.redhat.com/show_bug.cgi?id=463573 Description of problem (excerpt) : "In a virtual environment, timekeeping for RHEL 64 bit kernels can be problematic, since time is kept by counting timer interrupts for this kernel. The problem arises when the VM is descheduled for some

This is really stupid question. But referring to: http://lists.centos.org/pipermail/centos/2009-October/083791.html I don't see any line related to ntpd in my /var/log/messages . Do I need to turn-on ntpd for timekeeping on VMs? Some people say not to use ntpd on VMs for timekeeping or is it ntpdate cron job? Can someone please elaborate on this? Thanks, Jonathan. -------------- next part

Before 6.X Syslinux used a "Tick-less" timekeeping approach implemented in /core/bios.inc 6.X now implements a "Tick-counting" strategy (timer interrupt) implemented in /core/timer.inc I think this change presents issues when Sysylinux runs on Virtual Machines emulating a BIOS environment as they cannot correctly emulate the timer interrupt; see VMware's pdf:

A NO_IDLE_HZ implementation is provided for i386 VMI builds. When a VCPU enters its idle loop, it disables its periodic alarm and sets up a one shot alarm for the next time event. That way, it does not become ready to run just to service the periodic alarm interrupt. Instead, it can remain halted until there is some real work pending for it. This allows the hypervisor to use the physical

A NO_IDLE_HZ implementation is provided for i386 VMI builds. When a VCPU enters its idle loop, it disables its periodic alarm and sets up a one shot alarm for the next time event. That way, it does not become ready to run just to service the periodic alarm interrupt. Instead, it can remain halted until there is some real work pending for it. This allows the hypervisor to use the physical

Uses NEON optimized fixed point fft routines in NE10 library Signed-off-by: Viswanath Puttagunta <viswanath.puttagunta at linaro.org> Signed-off-by: Jonathan Lennox <jonathan at vidyo.com> --- Makefile.am | 12 +- celt/arm/arm_celt_map.c | 46 ++-- celt/arm/celt_ne10_fft.c | 98 +++++---- celt/arm/fft_arm.h |

Hello, I was thinking of creating a wiki page about Xen clocksources and timekeeping.. including dom0, PV guests and HVM guests. Dan and Jeremy: You guys might have some ideas for this page.. please let me know your thoughts :) Subjects to cover: - Xen hypervisor clocksources (hpet, acpi_pm, pit) - Xen dom0 clocksource, ntpd, etc - Xen PV guest clocksources, independent_wallclock, ntpd,

> > There are quite a few; primarily we simply cannot make lwIP > (lpxelinux.0) work without it. However, pxelinux.0 should not depend on > this. I'm finding most of the problems on lpxelinux.0 > >Now, tickful timekeeping is wasteful, but this is a bootloader, and >functionality is the main concern. The "tickless" version still >depended on the BIOS

On 03/03/16 09:18, Patrick Masotta wrote: >>>> How so? > > it says they cannot emulate the timer interrupt very well; > that's what I understood... If it's the VMware document I'm thinking of (titled "Timekeeping in VMware Virtual Machines"), then the issue is that emulating the timer interrupt can cause a heavy load on the host if the guest timer is