From: Dave Jones <davej@redhat.com>
To: nemesis@icequake.net
Cc: Cpufreq@lists.linux.org.uk
Subject: Re: writing a cpufreq driver
Date: Fri, 22 Sep 2006 11:51:05 -0400 [thread overview]
Message-ID: <20060922155105.GC15032@redhat.com> (raw)
In-Reply-To: <20060922143954.GF24439@dbz.icequake.net>
On Fri, Sep 22, 2006 at 09:39:54AM -0500, Ryan Underwood wrote:
>
> On Fri, Sep 22, 2006 at 09:13:18AM -0500, Ryan Underwood wrote:
> >
> > I have a question, how critical is it that I have exactly the correct
> > CPU MHz for the scaling to work properly? Unfortunately, for the slow
> > speed there is no way for me to know what it actually is on a particular
> > system due to limitations of the firmware, so the best I could do is a
> > RDTSC timing to try to figure it out. I wonder if skew between the
> > actual CPU speed and what cpufreq thinks it is would be the source of
> > the problem.
>
> Hmm, this might have been the problem. On my machine, the fast and slow
> MHz (as measured by my TSC routine) are the same. However, the machine
> is noticeably slower at the 'slow' firmware setting. I thought maybe
> they were disabling L1 cache, but that is not the case. The CPU is a
> Pentium VRT 120MHZ so I'm not sure what is going on.... maybe down
> clocking the system bus or memory or inserting wait states somewhere.
>
> In any case, since the fast and slow MHZ are the same, cpufreq does
> nothing. But cpufreq should still do "something" in this case, since
> something else that my driver does is to disable the L2 cache when going
> to the slow state, which is a decent power savings even on my laptop
> that doesn't have an actual slow MHZ. But since the fast and slow mhz
> are the same, cpufreq performs no actions.
*shrug*, I'm out of ideas. I looked over your code, and it seems to
be correctly doing notifications when it performs a transition,
which should be taking care of the timing issues for you.
Puzzlings.
Dave
next prev parent reply other threads:[~2006-09-22 15:51 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-21 18:48 writing a cpufreq driver Ryan Underwood
2006-09-21 19:31 ` Dave Jones
2006-09-21 19:38 ` Langsdorf, Mark
2006-09-21 19:47 ` Dave Jones
2006-09-22 15:44 ` Bruno Ducrot
2006-09-22 15:49 ` Dave Jones
2006-09-21 20:08 ` Ryan Underwood
2006-09-21 20:44 ` Dave Jones
2006-09-21 21:03 ` Ryan Underwood
2006-09-21 21:13 ` Dave Jones
2006-09-22 14:13 ` Ryan Underwood
2006-09-22 14:39 ` Ryan Underwood
2006-09-22 15:48 ` Bruno Ducrot
2006-09-22 16:01 ` Ryan Underwood
2006-09-22 15:51 ` Dave Jones [this message]
2006-09-22 15:39 ` Bruno Ducrot
2006-09-22 16:00 ` Ryan Underwood
2006-09-22 16:05 ` Bruno Ducrot
2006-09-22 16:11 ` Ryan Underwood
2006-09-23 15:07 ` Bruno Ducrot
2006-09-23 15:21 ` Ryan Underwood
2006-09-23 15:44 ` Bruno Ducrot
2006-09-23 16:03 ` Ryan Underwood
2006-09-23 16:13 ` Bruno Ducrot
2006-09-25 15:39 ` Ryan Underwood
2006-10-02 2:19 ` Dominik Brodowski
2006-09-25 16:44 ` Ryan Underwood
-- strict thread matches above, loose matches on Subject: below --
2006-09-22 16:31 Erik Slagter
2006-09-23 15:31 ` Bruno Ducrot
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=20060922155105.GC15032@redhat.com \
--to=davej@redhat.com \
--cc=Cpufreq@lists.linux.org.uk \
--cc=nemesis@icequake.net \
/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