Messages in this thread | | | Date | Wed, 17 Aug 2005 20:10:30 +0400 | From | Stas Sergeev <> | Subject | Re: [rfc][patch] API for timer hooks |
| |
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:)
- 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/
| |