Re: [PATCH] maximum latency tracking infrastructure (version 3)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Mon, Aug 28, 2006 at 06:19:27PM +0200, Arjan van de Ven wrote:
> I could have sworn there was an idle call notifier already\
> 
> ah there is on x86-64 but it is architecture specific...

So we would already have something that could be extended.

BTW, my IRQ statement was misplaced since this is the very thing we're
caring about: de-idle activation latency right after hardware IRQ occurred.
IOW, an idle callback really could be useful, since it does
positively work against the buffer servicing IRQ wakeup latency issue.

Another question is how one would do callback processing in idle handler:
one could figure out the idle mode (latency) in advance and *then* call
only all those idle callbacks that have more stringent requirements
than the currently calculated idle mode's latency (and then calculate
the idle mode again based on the current time after all those callbacks??),
or one could just unconditionally call all idle handlers and then figure out
idle length and go to sleep. Which one is better?

Andreas Mohr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux