Re: why do we have wall_jiffies?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux