linux-kernel - [RFC][PATCH 0/3] c-state governor changes

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-next>] [day] [month] [year] [list]

Message-ID: <20120823171104.38574add@cuia.bos.redhat.com>
Date:	Thu, 23 Aug 2012 17:11:04 -0400
From:	Rik van Riel <riel@...hat.com>
To:	linux-kernel@...r.kernel.org
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, ShuoX Liu <shuox.liu@...el.com>,
	mjg59@...f.ucam.org, Boris Ostrovsky <boris.ostrovsky@....com>,
	Len Brown <len.brown@...el.com>,
	Deepthi Dharwar <deepthi@...ux.vnet.ibm.com>,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: [RFC][PATCH 0/3] c-state governor changes

It turns out that the c-state governor can be a performance issue
with certain workloads.  The problem workloads seem to involve
mixed length pauses between activities, eg. an occasional long
idle period, with a burst of activity involving short idle periods.

One example of this would be a system with a web server and a
database, where the web server gets a request "every once in a
while" (compared to c-state timescales), and then quickly bounces
stuff back and forth between itself and the database, before
sending anything back to the http client.

On the face of it, the use of average sleep times does not make
a whole lot of sense, when we can have sleep patterns like this:

	150 200 50 1000 30 180 10000 220

The bulk of the sleep time is spent in the one long sleep, but
planning for a 1500us sleep time (around the average) is pretty
much guaranteed to be wrong.

Instead, it might make more sense to plan for a sleep time just
under 200us. We may still need some kind of demotion scheme to
kick us into a deeper c-state when a truly long sleep period
comes along...

This patch set is mostly there to kick off a discussion in time
for Kernel Summit.  When running it on my laptop, with acpi_idle,
I see a promising change in powertop.

Time spent in C3 has gone down from 99% of CPU time, to 97-98% CPU 
time, but the average residency time in C3 has gone up.  The other
1-2% of CPU time is spent in C2 instead.

I have not run any meaningful benchmarks against this code yet.
It has had a benchmark run where the workload presents regular
sleep intervals, and performs identically to the old code.

Please let me know what you think :)

-- 
All Rights Reversed
--
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/