public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Thomas Renninger <trenn@suse.de>
Cc: Frank Sorenson <frank@tuxrocks.com>,
	linux-kernel@vger.kernel.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Pavel Machek <pavel@suse.cz>,
	Arjan van de Ven <arjan@infradead.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Andrea Arcangeli <andrea@suse.de>,
	George Anzinger <george@mvista.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	john stultz <johnstul@us.ibm.com>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>,
	Lee Revell <rlrevell@joe-job.com>
Subject: Re: [PATCH] Updated: Dynamic Tick version 050408-1
Date: Fri, 8 Apr 2005 04:55:36 -0700	[thread overview]
Message-ID: <20050408115535.GI4477@atomide.com> (raw)
In-Reply-To: <42566C22.4040509@suse.de>

* Thomas Renninger <trenn@suse.de> [050408 04:34]:
> 
> Here are some figures about idle/C-states:
> 
> Passing bm_history=0xF to processor module makes it going into C3 and deeper.
> Passing lower values, deeper states are reached more often, but system could freeze:

Hmm, I wonder why it freezes? Is it ACPI issue or related to dyn-tick?
 
> Figures NO_IDLE_HZ disabled, HZ=1000 (max sleep 1ms)
...
> Total switches between C-states:  20205
> Switches between C-states per second:  1063 per second
> 
> Figures NO_IDLE_HZ enabled, processor.bm_history=0xF HZ=1000:
...
> Total switches between C-states:  4659
> Switches between C-states per second:  65 per second

The reduction in C state changes should produce some power savings,
assuming the C states do something...

> I buffer C-state times in an array and write them to /dev/cstX.
> From there I calc the stats from userspace.
> 
> Tony: If you like I can send you the patch and dump prog for
> http://www.muru.com/linux/dyntick/ ?

Yeah, that would nice to have!

> I try to find a better algorithm (directly adjust slept time to
> C-state latency or something) for NO_IDLE_HZ (hints are very welcome)
> and try to come up with new figures soon.

I suggest we modify idle so we can call it with the estimated sleep
length in usecs. Then the idle loop can directly decide when to go to
C2 or C3 depening on the estimated sleep length.

Tony

  reply	other threads:[~2005-04-08 11:56 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-06  8:30 [PATCH] Dynamic Tick version 050406-1 Tony Lindgren
2005-04-06 21:16 ` Frank Sorenson
2005-04-07  8:21   ` Tony Lindgren
2005-04-07  9:26     ` Alexander Nyberg
2005-04-08  6:22       ` Tony Lindgren
2005-04-07 21:35     ` Frank Sorenson
2005-04-07 22:20       ` Frank Sorenson
2005-04-08  6:25         ` Tony Lindgren
2005-04-08  7:50           ` [PATCH] Updated: Dynamic Tick version 050408-1 Tony Lindgren
2005-04-08  8:49             ` Frank Sorenson
2005-04-08  9:17               ` Tony Lindgren
2005-04-08 21:42                 ` Frank Sorenson
2005-04-09  8:09                   ` Tony Lindgren
2005-04-08 11:33               ` Thomas Renninger
2005-04-08 11:55                 ` Tony Lindgren [this message]
2005-04-08 12:58                   ` Thomas Renninger
2005-04-09  8:22                     ` Tony Lindgren
2005-04-19 14:56                   ` [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures Thomas Renninger
2005-04-19 15:27                     ` Dominik Brodowski
2005-04-19 21:03                       ` Thomas Renninger
2005-04-20 11:44                         ` Dominik Brodowski
2005-04-20 11:57                           ` Pavel Machek
2005-04-20 12:01                             ` Dominik Brodowski
2005-04-20 12:08                               ` Pavel Machek
2005-04-20 12:13                                 ` Dominik Brodowski
2005-04-20 12:24                           ` Thomas Renninger
2005-04-19 21:09                     ` Pavel Machek
2005-04-20 20:01                       ` Tony Lindgren
2005-04-21  7:54                         ` Thomas Renninger
2005-04-08 10:28             ` [PATCH] Updated: Dynamic Tick version 050408-1 Pavel Machek
2005-04-08 10:54               ` Tony Lindgren
2005-04-08 12:24                 ` Pavel Machek
2005-04-09  9:56                 ` Pavel Machek
2005-04-14 19:41                   ` Tony Lindgren

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=20050408115535.GI4477@atomide.com \
    --to=tony@atomide.com \
    --cc=andrea@suse.de \
    --cc=arjan@infradead.org \
    --cc=benh@kernel.crashing.org \
    --cc=frank@tuxrocks.com \
    --cc=george@mvista.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    --cc=rlrevell@joe-job.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=trenn@suse.de \
    --cc=zwane@arm.linux.org.uk \
    /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