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
next prev parent 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