Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5

[Ingo Molnar]

* Roman Zippel <zippel@xxxxxxxxxxxxxx> wrote:

> > > It's rather simple:
> > > - "timer API" vs "timeout API": I got absolutely no acknowlegement that this
> > > might be a little confusing and in consequence "process timer" may be a
> > > better name.
> > 
> > I agree with Thomas on this one.  Maybe "timer" and "timeout" are too close,
> > but I think they are the most descriptive names.
> >  - timeout is something used for a timeout.  Timeouts only actually
> >  expire infrequently, so they have a host of attributes associated
> >  with that characteristic.
> >  - timer is something used to time something.  They almost always
> >  expire as part of their normal behaviour.  In the ktimer code they
> >  have a host of attributes related to this characteristic.
> 
> There is of course a difference, but is it big enough that they 
> deserve different APIs? Just look into <linux/timer.h> it doesn't 
> mention timeout once, but according to Thomas that's our "timeout 
> API". Look at the description of mod_timer() in timer.c: "modify a 
> timer's timeout". It seems I'm not only one who thinks that both are 
> closely related.

this is one more area where there's no good substitute from 'walking the 
walk', i.e. getting yourself dirty with actual code. I have been 
involved with the following variants which were part of the -rt tree:

- we implemented both timeouts and timers with the same
  timeout-optimized framework [i.e. with the 'wheel'] - it sucked.

- timers and timeouts with a timer-optimized framework [i.e. with a
  binary tree] sucks too, due to the tree overhead.

- we in fact tried another variant too: a hybrid method where timers and
  timeouts lived in the timer wheel and some time before (hr) timers
  were about to time out they were put into a separate hr-list. This
  hybrid solution sucked too.

so then we tried a separate API and subsystem for both of them, and 
voila, many of the uglinesses went away, and things became robust.

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