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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 Aug 2006 15:43:44 +0200
From:	"Jan Kiszka" <jan.kiszka@...glemail.com>
To:	"Arjan van de Ven" <arjan@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org, len.brown@...el.com, mingo@...e.hu,
	akpm@...l.org, jbarnes@...tuousgeek.org, dwalker@...sta.com,
	nickpiggin@...oo.com.au, rpm@...omai.org
Subject: Re: [RFC] maximum latency tracking infrastructure (version 2)

2006/8/25, Arjan van de Ven <arjan@...ux.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@...ux.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/