From: Dominik Brodowski <linux@brodo.de>
To: Carl Thompson <cet@carlthompson.net>
Cc: cpufreq@www.linux.org.uk, "Nakajima,
Jun" <jun.nakajima@intel.com>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
"Mallick, Asit K" <asit.k.mallick@intel.com>,
arjanv@redhat.com, linux-acpi <linux-acpi@intel.com>
Subject: Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver
Date: Tue, 21 Oct 2003 22:39:00 +0200 [thread overview]
Message-ID: <20031021203900.GG26971@brodo.de> (raw)
In-Reply-To: <1066766155.a66ff46274f08@carlthompson.net>
On Tue, Oct 21, 2003 at 12:55:55PM -0700, Carl Thompson wrote:
> Quoting "Nakajima, Jun" <jun.nakajima@intel.com>:
>
> > ...
>
> > It's about the frequency of the feedback loop. As we have much lower
> > latency with P-state transitions, the sampling time can be order of
> > millisecond (or shorter if meaningful). A userland daemon can have a
> > high-level policy (preferences, or set of parameters), but it cannot be
> > part of the real feedback loop. If we combine P-state transitions and
> > deeper C-state transitions, the situation is worse with a userland
> > daemon.
>
> You are making the assumption that a higher polling frequency (we'll say
> 1ms) is in general better than a lower frequency (we'll say 1s). I submit
> that it is not.
>
> If I hit a key on my keyboard and your high frequency loop increases CPU
> speed so that my word processor displays the letter 0.01s faster, is that
> really beneficial? If a window renders in 0.2s seconds instead of 0.3s is
> that a difference I am going to notice?
>
> On the other hand, if I do a kernel compile and it is done 0.999s faster
> with the higher frequency loop, am I going to miss that second over such a
> long duration? (In reality, the compile with the high-frequency loop would
> probably take longer unless it has near zero overhead).
>
> In my opinion it is wasteful to increase CPU speed unless there is a longer
> term need for it.
Different needs, different opinions, different governors...
Dominik
next prev parent reply other threads:[~2003-10-21 20:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-21 15:47 [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver Nakajima, Jun
2003-10-21 15:47 ` Nakajima, Jun
2003-10-21 19:55 ` Carl Thompson
2003-10-21 19:55 ` Carl Thompson
2003-10-21 20:39 ` Dominik Brodowski [this message]
2003-10-22 7:18 ` Arjan van de Ven
2003-10-22 7:18 ` Arjan van de Ven
-- strict thread matches above, loose matches on Subject: below --
2003-10-21 17:41 Pallipadi, Venkatesh
2003-10-21 17:41 ` Pallipadi, Venkatesh
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=20031021203900.GG26971@brodo.de \
--to=linux@brodo.de \
--cc=arjanv@redhat.com \
--cc=asit.k.mallick@intel.com \
--cc=cet@carlthompson.net \
--cc=cpufreq@www.linux.org.uk \
--cc=jun.nakajima@intel.com \
--cc=linux-acpi@intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.