From: David C Niemi <dniemi@verisign.com>
To: Dirk Brandewie <dirk.brandewie@gmail.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>,
cpufreq@vger.kernel.org, rjw@sisk.pl, deneen.t.dock@intel.com
Subject: Re: [PATCH RFC 0/1] cpufreq/x86: Add P-state driver for sandy bridge.
Date: Thu, 06 Dec 2012 13:41:07 -0500 [thread overview]
Message-ID: <50C0E6C3.4010407@verisign.com> (raw)
In-Reply-To: <50C0E30B.2040301@gmail.com>
On 12/06/12 13:25, Dirk Brandewie wrote:
>
> Without being VERY intimate with scheduler it is not clear how you could get
> here. How can the governor know which core should get the most performance?
>
> When we request a frequency greater than the frequency stamped on the part
> (turbo frequency) the processor opportunistically run at a higher frequency
> upto the requested frequency.
I think being that intimate between the scheduler and the driver is probably not worth the considerable complexity it would introduce.
One bit of general user input I can see being relevant is whether to even consider using power-expensive modes like turbo frequencies at all. In the first 2 or 3 of Arjan's settings, yes, you would. In the last two you would never use them. If you were optimizing for multithreaded performance you might also not want to use them, but perhaps the CPU would be happy to handle that decision for you, as Arjan suggests, so it may not be worth trying to control it top-down.
...
> Keeping an average over time is clearly possible in the driver but it is not clear how it would be useful. In most situations other that proving that the
> frequency changes over time there is little useful information provided
> by knowing the current operating frequency.
I don't think knowing a precise frequency at a precise time is very critical, but finding something to report would help make users feel the driver is working well. Having low overhead in collecting the information (like an average speed over a period of time) is more important than its precision or timeliness, as the most common use case is just a GUI feature.
>
> > to just report the max freq that the hardware thread is currently
>> eligible to use?
>>
>
> In Sandybridge you can request any turbo frequency at any time, what frequency
> you actually get is up to the hardware and you can't tell what frequency you actually got. AFAIK there is no way to tell what you are going to get
> when you request a frequency higher than the frequency stamped on the part.
So if it is not practical to get an average, reporting the frequency stamped on the part is better than nothing. It is boring, but less boring than reporting "0".
>
> --Dirk
DCN
next prev parent reply other threads:[~2012-12-06 18:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-05 19:01 [PATCH RFC 0/1] cpufreq/x86: Add P-state driver for sandy bridge dirk.brandewie
2012-12-05 19:01 ` [PATCH RFC 1/1] " dirk.brandewie
2012-12-05 20:28 ` [PATCH RFC 0/1] " David C Niemi
2012-12-05 21:01 ` Arjan van de Ven
2012-12-05 21:40 ` David C Niemi
2012-12-05 21:54 ` Arjan van de Ven
2012-12-06 15:01 ` David C Niemi
2012-12-06 16:27 ` Arjan van de Ven
2012-12-06 17:30 ` David C Niemi
2012-12-06 17:41 ` Arjan van de Ven
2012-12-06 18:25 ` Dirk Brandewie
2012-12-06 18:41 ` David C Niemi [this message]
2012-12-06 21:35 ` Dirk Brandewie
2012-12-06 22:23 ` David C Niemi
2012-12-06 20:45 ` Rafael J. Wysocki
2012-12-06 21:15 ` Arjan van de Ven
2012-12-06 21:26 ` Rafael J. Wysocki
2012-12-06 21:34 ` Rafael J. Wysocki
2012-12-06 22:08 ` Arjan van de Ven
2012-12-06 22:53 ` Rafael J. Wysocki
2012-12-06 16:35 ` Dirk Brandewie
2012-12-06 16:49 ` Arjan van de Ven
2012-12-06 18:16 ` David C Niemi
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=50C0E6C3.4010407@verisign.com \
--to=dniemi@verisign.com \
--cc=arjan@linux.intel.com \
--cc=cpufreq@vger.kernel.org \
--cc=deneen.t.dock@intel.com \
--cc=dirk.brandewie@gmail.com \
--cc=rjw@sisk.pl \
/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.