cpufreq Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Piel <Eric.Piel@tremplin-utc.net>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: cpufreq@zenii.linux.org.uk
Subject: Re: [PATCH][RFC] ondemand governor automatic downscaling
Date: Mon, 07 Mar 2005 01:53:41 +0100	[thread overview]
Message-ID: <422BA615.1010708@tremplin-utc.net> (raw)
In-Reply-To: <88056F38E9E48644A0F562A38C64FB600426C6CF@scsmsx403.amr.corp.intel.com>

Pallipadi, Venkatesh a écrit :
:
:
> In particular, this will not work well in the following situation:
> Assume a server with a constant read/write to disk. Say the CPU computes
> something for 40% of time and then issues a I/O and waits for remaining
> 60% of time (until I/O is complete). This wait is irrespective of CPU
> speed. Now if we reduce the frequency to make CPU 70% busy, and CPU will
> still wait for IO and overall performance will go down as a result of
> the frequency slowdown. 
> This can still happen with 20-80 policy, but the probablity is less.
Well, if I understand correctly, we lose time because the harddisk is 
waiting for the CPU to do some computing before it can write anything 
and the slowest is the CPU, the longer the harddisk will have to wait. 
IMHO, this situation seems very unlikely because of all the I/O 
virtualisation done by the kernel, including read-ahead and cache. The 
harddisk will completely turn asynchronously, 100% of the time, while 
the CPU will do computation during 70% of the time instead of 40%, still 
having idle time. This shouldn't affect global performance. Still, I can 
be overlooking something, do you have any testcase in mind?

In addition, in the very improbable case where disk would be waiting for 
the CPU (half idle), the 20-80 policy would have slight superiority 
simply because it is not as effective as the automatic downscaling 
policy. It would be better to directly address this problem, for 
instance, allowing the iowait time to count as busy time.


> 
> I am thinking of two possiblities here:
> 1) Keep ondemand as it is, with a performance oriented frequency
> scaling. And add a new governor with this automatic downscaling and with
> other features making it a power oriented frequency scaling.
> 2) Change the ondemand governor itself with these changes.
> 
> At present, I am tending towards option 1. But, I would like to get
> other opinions on this.
Well, I'd like to avoid as much as possible to have to fork the ondemand 
governor so I'd like to try to stick to option 2 :-)

Eric

  reply	other threads:[~2005-03-07  0:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-07  0:13 [PATCH][RFC] ondemand governor automatic downscaling Pallipadi, Venkatesh
2005-03-07  0:53 ` Eric Piel [this message]
2005-03-08 22:28   ` Stefan Seyfried
  -- strict thread matches above, loose matches on Subject: below --
2005-03-07  1:51 Pallipadi, Venkatesh
2005-03-06 23:36 Eric Piel

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=422BA615.1010708@tremplin-utc.net \
    --to=eric.piel@tremplin-utc.net \
    --cc=cpufreq@zenii.linux.org.uk \
    --cc=venkatesh.pallipadi@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