In kernel/timer.c we currently have jiffies_64, of which jiffies is
the least-significant long-sized piece, and wall_jiffies. The code
that updates them looks like this (from kernel/timer.c):
static inline void update_times(void)
{
unsigned long ticks;
ticks = jiffies - wall_jiffies;
if (ticks) {
wall_jiffies += ticks;
update_wall_time(ticks);
}
calc_load(ticks);
}
/*
* The 64-bit jiffies value is not atomic - you MUST NOT read it
* without sampling the sequence number in xtime_lock.
* jiffies is defined in the linker script...
*/
void do_timer(struct pt_regs *regs)
{
jiffies_64++;
update_times();
softlockup_tick(regs);
}
In other places there is code that uses (jiffies - wall_jiffies).
However I can't see any way that jiffies and wall_jiffies could ever
be different (except for a few nanoseconds while executing the code
above). I also can't see any way that `ticks' could ever be anything
other than 1.
Is the wall_jiffies stuff just a leftover from days when we used to do
timekeeping from a softirq? Or am I missing something fundamental?
Thanks,
Paul.
On Fri, 2006-02-17 at 16:56 +1100, Paul Mackerras wrote:
> In kernel/timer.c we currently have jiffies_64, of which jiffies is
> the least-significant long-sized piece, and wall_jiffies. The code
> that updates them looks like this (from kernel/timer.c):
>
> static inline void update_times(void)
> {
> unsigned long ticks;
>
> ticks = jiffies - wall_jiffies;
> if (ticks) {
> wall_jiffies += ticks;
> update_wall_time(ticks);
> }
> calc_load(ticks);
> }
>
> /*
> * The 64-bit jiffies value is not atomic - you MUST NOT read it
> * without sampling the sequence number in xtime_lock.
> * jiffies is defined in the linker script...
> */
>
> void do_timer(struct pt_regs *regs)
> {
> jiffies_64++;
> update_times();
> softlockup_tick(regs);
> }
>
> In other places there is code that uses (jiffies - wall_jiffies).
> However I can't see any way that jiffies and wall_jiffies could ever
> be different (except for a few nanoseconds while executing the code
> above). I also can't see any way that `ticks' could ever be anything
> other than 1.
>
> Is the wall_jiffies stuff just a leftover from days when we used to do
> timekeeping from a softirq? Or am I missing something fundamental?
Its only use right now is that on some arches we increment jiffies when
we detect lost ticks. This then forces xtime to be updated the
appropriate number of times.
It probably could be killed and the arches can just call do_timer() the
appropriate number of times. That might clean some things up. My TOD
work would also make it unnecessary.
thanks
-john
Oh, I missed this thread...
>>>>> On Fri, 17 Feb 2006 10:46:53 -0800, john stultz <[email protected]> said:
>> In other places there is code that uses (jiffies - wall_jiffies).
>> However I can't see any way that jiffies and wall_jiffies could
>> ever be different (except for a few nanoseconds while executing the
>> code above). I also can't see any way that `ticks' could ever be
>> anything other than 1.
>>
>> Is the wall_jiffies stuff just a leftover from days when we used to
>> do timekeeping from a softirq? Or am I missing something
>> fundamental?
john> Its only use right now is that on some arches we increment
john> jiffies when we detect lost ticks. This then forces xtime to be
john> updated the appropriate number of times.
Currently, jiffies and wall_jiffies is _really_ different most of
time. The jiffies is almost always one bigger than wall_jiffies (at
least on i386 and MIPS). Please refer my yesterday's mail (subject:
jiffies_64 vs. jiffies) for the reason.
john> It probably could be killed and the arches can just call
john> do_timer() the appropriate number of times. That might clean
john> some things up. My TOD work would also make it unnecessary.
I just posted a patch to doing this (subject: [PATCH] simplify
update_times ...). I thought only x86_64 is doing such thing, right?
Also, I suppose then we can get rid of wall_jiffies completely.
---
Atsushi Nemoto