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

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Tue, 18 Oct 2005, Ingo Molnar wrote:

> > Because they are optimized for process usage. OTOH kernel usage is 
> > more than just "timeouts".
> 
> you have cut out the rest of what i write in the paragraph, which IMO 
> answers your question:
> 
> > > They are totally separate entities, not limited to any process 
> > > notion. One of their first practical use happens to be POSIX process 
> > > timers (both itimers and ptimers) via them, but no way are ktimers 
> > > only 'process timers'. They are very generic timers, usable for any
> > > kernel purpose.
> 
> so i can only repeat that ktimers is a generic timer subsystem, with a 
> focus on _actually delivering a timer event_.

It doesn't answer it at all. The new timer system is definitively not 
"usable for any kernel purpose", it has certain properties, which makes it 
only applicable under certain conditions.

> and no, ktimers are not "optimized for process usage" (or tied to 
> whatever other process notion, as i said before), they are optimized 
> for:
> 
>  - the delivery of time related events
> 
> as contrasted to the timeout-API (a'ka "timer wheel") code in 
> kernel/timers.c that is optimized towards:
> 
>  - the fast adding/removal of timers
> 
> without too much focus on robust and deterministic delivery of events.

You forgot the main property of high resolution, which implies a higher 
maintainance cost. 
Whether the timer event is delivered or not is completely unimportant, as 
at some point the event has to be removed anyway, so that optimizing a 
timer for (non)delivery is complete nonsense.

> these two concepts are conflicting, and i claim that a (sane) data 
> structure that maximally fulfills both sets of requirements does not 
> exist, mathematically. (to repeat, the requirements are: 'fast 
> add/remove' and 'fast+deterministic expiry')

to repeat: low resolution/overhead vs high resolution.
Both are hopefully deterministic (only at different resolutions) or we 
have serious bug at hand.

> > > e.g. we dont want a watchdog from being 
> > > overload-able via too many timeouts in the timer wheel ...
> > 
> > Please explain.
> 
> e.g. on busy networked servers (i.e. ones that do have a need for 
> watchdogs) the timer wheel often includes large numbers of timeouts, 
> 99.9% of which never expire. If they do expire en masse for whatever 
> reason, then we can get into overload mode: a million timers might have 
> to expire before we get to process the watchdog event and act upon it.  
> This can delay the watchdog event significantly, which delay might (or 
> might not) matter to the watchdog application.

I already mentioned earlier that it's possible to reduce the timer load by 
using a watchdog timer to filter most of these events, so that you get 
into the interesting situation that most kernel timer actually do expire 
and suddenly you easily can have more "timers" than "timeouts".

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