Re: [PATCH v2 3/4] Implement clockevents driver for powerpc

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

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