public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Mohr <andi@lisas.de>
To: Andreas Mohr <andi@lisas.de>
Cc: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>,
	Corrado Zoccolo <czoccolo@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org
Subject: Re: Dynamic configure max_cstate
Date: Tue, 28 Jul 2009 16:03:08 +0200	[thread overview]
Message-ID: <20090728140308.GA17543@rhlx01.hs-esslingen.de> (raw)
In-Reply-To: <20090728101135.GA22358@rhlx01.hs-esslingen.de>

On Tue, Jul 28, 2009 at 12:11:35PM +0200, Andreas Mohr wrote:
> As a very quick test, I tried a
> while :; do :; done
> loop in shell and renicing shell to 19 (to keep my CPU out of ACPI idle),
> but bonnie -s 100 results initially looked promising yet turned out to
> be inconsistent. The real way to test this would be idle=poll.
> My test system was Athlon XP with /proc/acpi/processor/CPU0/power
> latencies of 000 and 100 (the maximum allowed value, BTW) for C1/C2.

OK, I just tested it properly.
Rebooted, did 5 bonnie -s 100 with ACPI idle, rebooted and did another 5
bonnie -s 100 with idle=poll, results:


$ cat bonnie_ACPI_* /tmp/line bonnie_poll_*
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
       1* 100 20084 95.3 19037  9.5 12286  4.7 18074 99.6 581752 96.6 28792.3 93.6
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
       1* 100 19235 93.5 24591 11.8 13916  4.3 17934 99.8 604429 100.3 27993.8 98.0
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
       1* 100 17221 86.3 30591 16.1 15404  5.4 18689 99.3 593296 92.7 28146.0 98.5
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
       1* 100 20254 99.3 110095 55.9 15722  6.1 17901 99.5 601185 99.8 28675.5 100.4
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
       1* 100 18274 88.5 106909 53.2 10614  4.1 18759 99.7 598833 99.4 28461.6 92.5
========
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
       1* 100 15274 98.2 20206  9.7 17286  7.3 18055 99.4 608112 101.0 28424.0 99.5
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
       1* 100 20545 99.1 25332 12.6 16392  6.1 17957 99.4 606706 100.7 27906.8 90.7
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
       1* 100 20482 99.2 30907 13.6 17585  6.2 17867 99.1 608090 101.0 27919.1 97.7
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
       1* 100 20863 99.4 138383 66.2 18945  7.6 17938 99.5 581421 96.5 27094.6 94.8
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
       1* 100 20821 98.8 156821 70.4 11536  4.4 18747 99.0 603556 100.2 27677.8 96.9


And these values (cumulative) result in:

         ACPI		poll
Per Char 95068		97985		+3.06%
Block   291223		371649		+27.62%
Rewrite	67942		81744		+20.31%
Per Char 91357		90564		-0.87%
Block  2979495		3007885		+0.95%
RndSeek	142069.2	139022.3	-2.1%
				average: +8.16%

Now the question is how much is due to idle state entry/exit latency
and how much is due to ACPI idle/wakeup code path execution.

Still, an average of +8.16% during 5 test runs each should be quite some incentive,
and once there's a proper "idle latency skipping during expected I/O replies"
even with idle/wakeup code path reinstated we should hopefully be able to keep
some 5% improvement in disk access.

Andreas Mohr

  reply	other threads:[~2009-07-28 14:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-27  5:30 Dynamic configure max_cstate Zhang, Yanmin
2009-07-27  7:33 ` Andreas Mohr
2009-07-28  2:42   ` Zhang, Yanmin
2009-07-28  7:20     ` Corrado Zoccolo
2009-07-28  9:00       ` Zhang, Yanmin
2009-07-28 10:11         ` Andreas Mohr
2009-07-28 14:03           ` Andreas Mohr [this message]
2009-07-28 17:35             ` ok, now would this be useful? (Re: Dynamic configure max_cstate) Andreas Mohr
2009-07-29  8:20           ` Dynamic configure max_cstate Zhang, Yanmin
2009-07-31  3:43           ` Robert Hancock
2009-07-31  7:06             ` Zhang, Yanmin
2009-07-31  8:07               ` Andreas Mohr
2009-07-31 14:40                 ` Andi Kleen
2009-07-31 14:56                   ` Michael S. Zick
2009-07-31 17:37                   ` Pallipadi, Venkatesh
2009-07-31 15:14                 ` Len Brown
2009-07-30  6:28         ` Zhang, Yanmin
2009-07-28 19:25       ` Len Brown
2009-07-29  0:17   ` Len Brown
2009-07-29  8:00     ` Andreas Mohr
2009-07-28 19:47 ` Len Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090728140308.GA17543@rhlx01.hs-esslingen.de \
    --to=andi@lisas.de \
    --cc=czoccolo@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yanmin_zhang@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox