Re: [RFC] maximum latency tracking infrastructure (version 2)

[Jan Kiszka]

2006/8/25, Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>:
> 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.

For sure, this risk remains unless SMI is fine-grained controllable
and you can avoid that cirtical services. It's a compromise between
not using common PC hardware for fast time critical jobs at all and a
small risk to loose hardware when something goes wrong anyway.

And such feature would certainly not be on by default. Even we don't
do this, the user must decide after being warned. I'm not aware of
complaints about damages after years of application in the field.

> > 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?

I was thinking about critical timed operations in userspace that are
not known to any driver ahead of time.

> 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".

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/