From: Tvrtko Ursulin <tvrtko.ursulin@sophos.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"mingo@elte.hu" <mingo@elte.hu>,
"peterz@infradead.org" <peterz@infradead.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"davej@redhat.com" <davej@redhat.com>,
"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>
Subject: Re: [PATCH 7/7] ondemand: Solve the big performance issue with ondemand during disk IO
Date: Wed, 28 Apr 2010 09:57:07 +0100 [thread overview]
Message-ID: <201004280957.07455.tvrtko.ursulin@sophos.com> (raw)
In-Reply-To: <20100420040207.1be74046@infradead.org>
On Tuesday 20 Apr 2010 12:02:07 Arjan van de Ven wrote:
> On Tue, 20 Apr 2010 10:10:49 +0100
>
> Tvrtko Ursulin <tvrtko.ursulin@sophos.com> wrote:
> > > it's better then to stay high longer... at least on modern machines
> > > the inbetween states are pretty much either useless or actually
> > > energy hurting compared to the higher state.
> >
> > Why do you think it is not good for latency to stay at higher
> > frequency for longer?
>
> oh it will be.
Well you said that "it's not even good for that ;-(" when I said that it may
be good for latency...
> > governor it was much much better. That is why I proposed to have a
> > gradual lowering as an option in on-demand. You said it already does
> > that - I ask are you sure? And also now you are saying it would not
> > be good for latency
> > - above is an example when it clearly does help (a lot).
>
> but the *gradual* lowering just does not make sense.
> might as well just stay at the highest frequency for the duration for
> which you do the gradual lowering, it's more efficient for power on most
> modern machines.
>
> The problem is if you do this gradual thing for long enough to help
> you on desktop loads, or the stay-high thing, on server workloads the
> power efficiency will completely and utterly tank. Been there tried
> that ;-)
Maybe it does not make sense for energy efficiency but it does for latency, I
think we have now agreed on that so it would be a nice knob to have. If I had
some time I would implement it if for nothing then to spice up this thread. :)
I also like Mike Chan's idea of minimum_full_io_speed_frequency parameter, in
addition to my gradual lowering.
> frankly, you're starting to touch at the more fundamental issues with
> ondemand. I'm not trying to solve that in this small patch, they really
> can only be solved in a complete redesign. While I'm doing such a
> redesign, I was asked to at least fix this particular gap urgently.
> Solving all of ondemand's issues needs a complete rethink of the core
> assumptions it makes (which are not correct anymore nowadays).
I understand that, although you gave no detail on how you designed this new
ondemand. Problem I have is that to me this workaround is quite ugly. If you
have to do it please add minimum_full_io_speed_frequency knob and also make it
default to current behaviour (no increase on iowait).
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
next prev parent reply other threads:[~2010-04-28 9:03 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-18 18:59 [PATCH 0/7] Fix performance issue with ondemand governor Arjan van de Ven
2010-04-18 19:00 ` [PATCH 1/7] sched: add a comment to get_cpu_idle_time_us() Arjan van de Ven
2010-04-26 19:25 ` Rik van Riel
2010-04-18 19:01 ` [PATCH 2/7] sched: introduce a function to update the idle statistics Arjan van de Ven
2010-04-26 20:11 ` Rik van Riel
2010-04-18 19:01 ` [PATCH 3/7] sched: update the idle statistics in get_cpu_idle_time_us() Arjan van de Ven
2010-04-26 20:36 ` Rik van Riel
2010-04-18 19:02 ` [PATCH 4/7] sched: fold updating of the last update time into update_ts_time_stats() Arjan van de Ven
2010-04-26 20:58 ` Rik van Riel
2010-04-18 19:02 ` [PATCH 5/7] sched: eliminate the ts->idle_lastupdate field Arjan van de Ven
2010-04-26 21:00 ` Rik van Riel
2010-04-18 19:03 ` [PATCH 6/7] sched: introduce get_cpu_iowait_time_us() Arjan van de Ven
2010-04-26 21:05 ` Rik van Riel
2010-04-18 19:03 ` [PATCH 7/7] ondemand: Solve the big performance issue with ondemand during disk IO Arjan van de Ven
2010-04-19 8:29 ` Éric Piel
2010-04-19 13:43 ` Arjan van de Ven
2010-04-19 14:30 ` Éric Piel
2010-04-19 14:47 ` Arjan van de Ven
2010-04-20 9:24 ` Thomas Renninger
2010-04-27 0:29 ` Mike Chan
2010-04-27 13:01 ` Pavel Machek
2010-04-27 18:10 ` Mike Chan
2010-04-19 9:09 ` Tvrtko Ursulin
2010-04-19 13:46 ` Arjan van de Ven
2010-04-19 15:29 ` Tvrtko Ursulin
2010-04-20 0:47 ` Arjan van de Ven
2010-04-20 9:10 ` Tvrtko Ursulin
2010-04-20 11:02 ` Arjan van de Ven
2010-04-28 8:57 ` Tvrtko Ursulin [this message]
2010-04-23 5:26 ` Pavel Machek
2010-04-20 9:29 ` Thomas Renninger
2010-04-20 11:07 ` Arjan van de Ven
2010-04-23 5:24 ` Pavel Machek
2010-04-23 5:38 ` Willy Tarreau
2010-04-23 8:50 ` Thomas Renninger
2010-04-23 16:08 ` Arjan van de Ven
2010-04-27 11:39 ` Thomas Renninger
2010-05-04 3:48 ` [PATCH 8/7] cpufreq: make the iowait-is-busy-time a sysfs tunable Arjan van de Ven
2010-05-04 4:16 ` Willy Tarreau
2010-05-04 5:43 ` Pavel Machek
2010-05-04 13:51 ` Rik van Riel
2010-04-23 14:10 ` [PATCH 7/7] ondemand: Solve the big performance issue with ondemand during disk IO Arjan van de Ven
2010-04-23 15:35 ` Willy Tarreau
2010-04-23 13:52 ` Arjan van de Ven
2010-04-23 8:38 ` Pavel Machek
2010-04-23 16:06 ` Arjan van de Ven
2010-04-24 4:56 ` Pavel Machek
2010-05-01 23:29 ` Arjan van de Ven
2010-04-26 21:30 ` Rik van Riel
2010-04-26 21:41 ` [PATCH 0/7] Fix performance issue with ondemand governor Dave Jones
2010-04-26 21:45 ` Dominik Brodowski
2010-04-26 21:59 ` Rik van Riel
2010-04-26 22:05 ` Dominik Brodowski
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=201004280957.07455.tvrtko.ursulin@sophos.com \
--to=tvrtko.ursulin@sophos.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=cpufreq@vger.kernel.org \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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
Powered by JetHome