Re: [topic change] jiffies as a time value

[George Anzinger <george@mvista.com>]

john stultz wrote:
> On Mon, 2005-03-14 at 15:40 -0800, George Anzinger wrote:
> 
>>john stultz wrote:
>>
>>>On Sat, 2005-03-12 at 16:49 -0800, Matt Mackall wrote:
>>>
>>>>>+	/* finally, update legacy time values */
>>>>>+	write_seqlock_irqsave(&xtime_lock, x_flags);
>>>>>+	xtime = ns2timespec(system_time + wall_time_offset);
>>>>>+	wall_to_monotonic = ns2timespec(wall_time_offset);
>>>>>+	wall_to_monotonic.tv_sec = -wall_to_monotonic.tv_sec;
>>>>>+	wall_to_monotonic.tv_nsec = -wall_to_monotonic.tv_nsec;
>>>>>+	/* XXX - should jiffies be updated here? */
>>>>
>>>>Excellent question. 
>>>
>>>Indeed.  Currently jiffies is used as both a interrupt counter and a
>>>time unit, and I'm trying make it just the former. If I emulate it then
>>>it stops functioning as a interrupt counter, and if I don't then I'll
>>>probably break assumptions about jiffies being a time unit. So I'm not
>>>sure which is the easiest path to go until all the users of jiffies are
>>>audited for intent. 
>>
>>Really?  Who counts interrupts???  The timer code treats jiffies as a unit of 
>>time.  You will need to rewrite that to make it otherwise.  
> 
> 
> Ug. I'm thin on time this week, so I was hoping to save this discussion
> for later, but I guess we can get into it now.
> 
> Well, assuming timer interrupts actually occur HZ times a second, yes
> one could (and current practice, one does) implicitly interpret jiffies
> as being a valid notion of time.  However with SMIs, bad drivers that
> disable interrupts for too long, and virtualization the reality is that
> that assumption doesn't hold. 
> 
> We do have the lost-ticks compensation code that tries to help this, but
> that conflicts with some virtualization implementations. Suspend/resume
> tries to compensate jiffies for ticks missed over time suspended, but
> I'm not sure how accurate it really is (additionally, looking at it now,
> it assumes jiffies is only 32bits).
> 
> Adding to that, the whole jiffies doesn't really increment at HZ, but
> ACTHZ confusion, or bad drivers that assume HZ=100, we get a fair amount
> of trouble stemming from folks using jiffies as a time value.  Because
> in reality, it is just a interrupt counter.

Well, currently, in x86 systems it causes wall clock to advance a very well 
defined amount.  That it is not exactly 1/HZ is something we need to live with...
> 
> So now, if new timeofday code emulates jiffies, we have to decide if it
> emulates jiffies at HZ or ACTHZ? Also there could be issues with jiffies
> possibly jittering from it being incremented every tick and then set to
> the proper time when the timekeeping code runs. 

I think your overlooking timers.  We have a given resolution for timers and some 
code, at least, expects timers to run with that resolution.  This REQUIRES 
interrupts at resolution frequency.  We can argue about what that interrupt 
event is called (currently a jiffies interrupt) and disparage the fact that 
hardware can not give us "nice" numbers for the resolution, but we do need the 
interrupts.  That there are bad places in the code where interrupts are delayed 
is not really important in this discussion.  For what it worth, the RT patch 
Ingo is working on is getting latencies down in the 10s of microseconds region.

We also need, IMNSHO to recognize that, at lest with some hardware, that 
interrupt IS in fact the clock and is the only reasonable way we have of reading 
it.  This is true, for example, on the x86.  The TSC we use as a fill in for 
between interrupts is not stable in the long term and should only be used to 
interpolate over 1 to 10 ticks or so.
> 
> I'm not sure which is the best way to go, but it sounds that emulating
> it is probably the easiest. I just deferred the question with a comment
> until now because its not completely obvious. Any suggestions on the
> above questions (I'm guessing the answers are: use ACTHZ, and the jitter
> won't hurt that bad). 
> 
> 
>>But then you have 
>>another problem.  To correctly function, times need to expire on time (hay how 
>>bout that) not some time later.  To do this we need an interrupt source.  To 
>>this point in time, the jiffies interrupt has been the indication that one or 
>>more timer may have expired.  While we don't need to "count" the interrupts, we 
>>DO need them to expire the timers AND they need to be on time.
> 
> 
> Well, something Nish Aravamudan has been working on is converting the
> common users of jiffies (drivers) to start using human time units. These
> very well understood units (which avoid HZ/ACTHZ/HZ=100 assumptions) can
> then be accurately changed to jiffies (or possibly some other time unit)
> internally. It would even be possible for soft-timers to expire based
> upon the actual high-res time value, rather then the low-res tick-
> counter(which is something else Nish has been playing with). When that
> occurs we can easily start doing other interesting things that I believe
> you've already been working on in your HRT code, such as changing the
> timer interrupt frequency dynamically, or working with multiple timer
> interrupt sources. 

This is also what is done in things like posix timers.  The fact remains that, 
at least in the posix timers case, the resolution is exported to the user and 
implies certain things.  I am not sure we are explicitly exporting the 
resolution in the kernel, but, down under the code, there is a resolution AND it 
impacts what one should expect of timers.
> 
> So basically, lots of interesting questions and possibilities and I very
> much look forward to your input and suggestions. 
> 
It may help to understand that MOST internal timers (i.e. timers the kernel 
sets) never expire.  They are canceled by the caller because they were really 
"dead man" timers, i.e. "it better happen be this time or we are hurting".

Users, on the other hand, for the most part set up timers to allow bits of code 
to run either periodically or at some specified time.  These are the folks who 
care about latency and being on time.

User also, of course, also use "dead man" timers such as, for example, the time 
out on select.  By their nature the "dead man" timer, usually, does not have 
strict on time requirements.
-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/