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

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

 



2006/8/25, Arjan van de Ven <[email protected]>:
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 <[email protected]>

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