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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
