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

["Jan Kiszka" <jan.kiszka@googlemail.com>]

2006/8/25, Arjan van de Ven <arjan@linux.intel.com>:
> New in this version:
> * implemented the various comments on the code
> * implemented a notifier mechanism so that code can serialize on latency (Nick)
> * put the max latency in the ACPI C states file
>
> One open question is if the sysreq key is considered useful or only a bad hack..
>
>
>
> Subject: [RFC] maximum latency tracking infrastructure
> From: Arjan van de Ven <arjan@linux.intel.com>
>
> 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 (compile-time configurable).
But maybe this could be done in a smarter fashion in mainline
directly. It would likely take some practical boundary (SMI latencies
are fairly board / bios dependent) and a place to put the simple check

    if (system_latency_constraint() < SMI_LATENCY) disable_smi();

Maybe vendors will provide more information on SMI-related latencies,
how to avoid them, and what side effects exist once an infrastrure is
there.

If there is some common interest in this direction, I would try to
spend time on working out a patch based on your infrastructure and our
current material in Xenomai. Or is there already something planned in
this direction?

>
> The reason for adding this infrastructure is that power management in the
> idle loop needs to make a tradeoff between latency and power savings (deeper
> power save modes have a longer latency to running code again).  The code
> that today makes this tradeoff just does a rather simple algorithm; however
> this is not good enough: There are devices and use cases where a lower
> latency is required than that the higher power saving states provide. An
> example would be audio playback, but another example is the ipw2100 wireless
> driver that right now has a very direct and ugly acpi hook to disable some
> higher power states randomly when it gets certain types of error.
>
> The proposed solution is to have an interface where drivers can
> * announce the maximum latency (in microseconds) that they can deal with
> * modify this latency
> * give up their constraint
> and a function where the code that decides on power saving strategy can query
> the current global desired maximum.

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

Jan