[topic change] jiffies as a time value

[john stultz <johnstul@us.ibm.com>]

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.

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'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. 

So basically, lots of interesting questions and possibilities and I very
much look forward to your input and suggestions. 

thanks
-john