mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andreas Mohr <andi@rhlx01.fht-esslingen.de>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, mingo@elte.hu,
	jesse.barnes@intel.com, dwalker@mvista.com
Subject: Re: [PATCH] maximum latency tracking infrastructure (version 3)
Date: Mon, 28 Aug 2006 18:35:31 +0200	[thread overview]
Message-ID: <20060828163531.GA8257@rhlx01.fht-esslingen.de> (raw)
In-Reply-To: <44F3178F.8010508@linux.intel.com>

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

  parent reply	other threads:[~2006-08-28 16:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-28 15:48 Arjan van de Ven
2006-08-28 16:11 ` Andreas Mohr
2006-08-28 16:19   ` Arjan van de Ven
2006-08-28 16:27     ` Andi Kleen
2006-08-28 16:35     ` Andreas Mohr [this message]
2006-08-28 16:48       ` Arjan van de Ven
2006-08-28 16:25 ` Jesse Barnes
2006-08-28 16:25   ` Arjan van de Ven
2006-08-28 16:30     ` Jesse Barnes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060828163531.GA8257@rhlx01.fht-esslingen.de \
    --to=andi@rhlx01.fht-esslingen.de \
    --cc=akpm@osdl.org \
    --cc=arjan@linux.intel.com \
    --cc=dwalker@mvista.com \
    --cc=jesse.barnes@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®