All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@linux.intel.com>
To: Jan Kiszka <jan.kiszka@googlemail.com>
Cc: linux-kernel@vger.kernel.org, len.brown@intel.com, mingo@elte.hu,
	akpm@osdl.org, jbarnes@virtuousgeek.org, dwalker@mvista.com,
	nickpiggin@yahoo.com.au, rpm@xenomai.org
Subject: Re: [RFC] maximum latency tracking infrastructure (version 2)
Date: Fri, 25 Aug 2006 15:48:56 +0200	[thread overview]
Message-ID: <44EEFFC8.40202@linux.intel.com> (raw)
In-Reply-To: <58d0dbf10608250643v1bb19d0ci99ae30243125a962@mail.gmail.com>

Jan Kiszka wrote:
>> The patch below adds infrastructure to track "maximum allowable 
>> latency" for
>> power saving policies.
> 
> Very interesting approach. I wonder if it could be used to cover
> another problematic source of latencies as well: asynchronous SMIs.
> They quickly cause delays reaching from a few 100 us up to
> milliseconds.
> 
> Hard-RT extension like Xenomai work around this on several Intel
> chipsets by disabling SMI unconditionally 


I would consider that a mistake. SMI's are used to do things like emergency thermal protections etc etc.
Disabling them unconditionally is going to risk you your hardware.

> I guess an interface to let also applications / the sysadmin specifiy
> a latency constraint would be useful as well. sysfs?

I thought about this a lot but decided against. There are already ways to do things like disable specific C states etc,
and if we expose this it'll mostly get abused by certain desktop applications who have no idea what they are doing ;=(
What makes anyone think that userspace could make a better decision than the drivers?
Video / Audio playback are not good examples since these both already would work automatically correct with only in-kernel
infrastructure. Hard-RT systems are also not a good example since those should use the existing boot parameters. I couldn't
come up with other scenarios, and until we have a good one I'm against exposing crap to sysfs "just because we can".

  reply	other threads:[~2006-08-25 13:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-25 11:22 [RFC] maximum latency tracking infrastructure (version 2) Arjan van de Ven
2006-08-25 13:30 ` Alexey Dobriyan
2006-08-25 13:34   ` Arjan van de Ven
2006-08-25 13:58   ` Ingo Molnar
2006-08-25 13:43 ` Jan Kiszka
2006-08-25 13:48   ` Arjan van de Ven [this message]
2006-08-25 14:18     ` Jan Kiszka
2006-08-25 15:15 ` Jesse Barnes
2006-08-25 15:43 ` Daniel Walker
2006-08-25 19:26   ` Arjan van de Ven
2006-08-25 19:35     ` Daniel Walker
2006-08-25 22:14 ` Andrew Morton

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=44EEFFC8.40202@linux.intel.com \
    --to=arjan@linux.intel.com \
    --cc=akpm@osdl.org \
    --cc=dwalker@mvista.com \
    --cc=jan.kiszka@googlemail.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=rpm@xenomai.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.