Re: [rfc][patch] API for timer hooks

[Stas Sergeev <stsp@aknet.ru>]

Hello.

Nish Aravamudan wrote:
>> [PATCH] i386: Selectable Frequency of the Timer Interrupt
>> but it doesn't look like it ended up
>> with some patch applied, or where is it?
> This thread resulted in CONFIG_HZ. You get to choose between 100, 250
> or 1000. It was not meant to allow runtime HZ modifications.
I see, but the thread was long, at one point
a lot have been said about setting HZ at boot -
that's something that most likely could be
usefull for me.

>> 2. It needs its handler to be executed
>> first in the chain. Otherwise the quality
>> is poor because of the latency.
> Yeah, that's a tougher one :)
Yes, but this can wait. Only the ability to
set the higher interrupt rates is vital.
But in fact, what is the problem to introduce
the grabbing timer within the current soft-timer
API? Or some priority scheme? I think it is
actually much easier to achieve than the variable
freq.

> Does the dynamic-tick patch help you at all? I'm not sure if it's
> meant to, admittedly.
I don't think it helps. It seems to be self-
contained. It doesn't add the generic API,
all its functions are using the specific
global structure, AFAICS.

> I'm also not sure if it has any cap on the
> maximum HZ it attempts to reprogram the hardware to... Mucking with HZ
> at run-time is going to break lots of stuff, though...well, not
> necessarily, depends on how you muck with jiffies :)
That's why I thought I should avoid this alltogether.
My patch introduces the grabbing hook, that
can decide to bypass the rest of the chain.
The idea is that it is now up to that hook
to make sure the rest of the chain is being
executed with the *old* frequency. Surely
this is a kind of an ad-hoc, but the change is
very small and seemingly innocent, plus the
cleanup - it may not be that bad after all, I
think:)