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, 31 Jul 2009 16:40:01 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
Cc:	Robert Hancock <hancockrwd@...il.com>,
	Corrado Zoccolo <czoccolo@...il.com>,
	LKML <linux-kernel@...r.kernel.org>, linux-acpi@...r.kernel.org,
	venkatesh.pallipadi@...el.com
Subject: Re: Dynamic configure max_cstate

Andreas Mohr <andi@...as.de> writes:

> Instead we should strive for a far-reaching _generic_ mechanism
> which gathers average latencies of various I/O activities/devices
> and then uses some formula to determine the maximum (not necessarily ACPI)
> idle latency that we're willing to endure (e.g. average device I/O reply latency
> divided by 10 or so).

The interrupt heuristics in the menu cpuidle governour are already
attempting this, based on interrupt rates (or rather
wakeup rates) which are supposed to roughly correspond with IO rates
and scheduling events together.

Apparently that doesn't work in this case. The challenge would
be to find out why and improve the menu algorithm to deal with it.
I doubt a completely new mechanism is needed or makes sense.

> And in addition to this, we should also take into account (read: skip)
> any idle states which kill busmaster DMA completely
> (in case of busmaster DMA I/O activities, that is)

This is already done.

-Andi
-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ