[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [GIT PULL RFC] pvclock cleanups and pvclock vsyscall support
On 10/15/2009 04:28 AM, Jeremy Fitzhardinge wrote: Hi all, This series contains several things: - Unify the separate vdso and vsyscall implementations of vgettimeofday and vgetcpu. There's at least one bugfix which was only applied to one copy (ignore tcache in vgetcpu was only applied to the vdso version); this should avoid such skews in future. - Bug fixes for the Xen and KVM clocksource.read functions to make sure the returned time doesn't regress compared to clocksource.cycle_last. (Probably stable material.) - Make sure the pvclock rdtsc is surrounded by appropriate barriers so that it doesn't get speculated to the wrong place with respect to reading the time parameters. (Probably stable material.) - General cleanups of the pvclock algorithm (there's no need to make a local copy of the time parameters before use). - Add a new CONFIG_X86_VSYSCALL to control the compilation of vsyscall-related code rather than just using CONFIG_X86_64 - we may want to implement 32-bit vsyscall at some point, and this will make it easier. - Add the sched notifier for task migration between CPUs, for use by pvclock vread. - Implement a pvclock vread function, so that pvclock-using clocksources can be used by vsyscall/vdso vgettimeofday and vclock_gettime. - Use pvclock vread in the Xen clocksource. Looks good to me. Acked-by etc. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |