Hello. Paul Mackerras wrote:
The xtime_lock is still grabbed by time_init()
Oops, I got distracted and hadn't finish the passage. My patch got rid of this xtime_lock stuff -- but this was in a different context, with all vDSO initialization code in between being killed by John's patch. I'm not sure it still has sense to hold this lock in time_init() around that initialization...
That was left in there because we are setting sys_tz
My patch moved that to read_persistent_clock()...
and do_gtod, and do_gtod at least is only updated with the xtime_lock held.
Of course, at that early stage in the boot process, no lock is really needed, but xtime_lock was taken for consistency with other code.
Thanks for claryfing this.
The only thing I'm still unusre about is that deterministic accounting. Could you point me at the patch which deals with this (at least for System 390
See efe567fc8281661524ffa75477a7c4ca9b466c63 in Linus' tree, and look
Wait, how this is related to the hrtimer's event handlers not being able to call account_process_time() from arch/powerpc/kernel/time.c instead of update_process_timess()?
for posts to lkml by Christian Borntraeger, who has been pursuing the issue (subject "Re: [stable] 2.6.23 regression: top displaying 9999% CPU usage").
Fun. :-)
Paul.
WBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
