From: Eric Piel <Eric.Piel@tremplin-utc.net>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: cpufreq@lists.linux.org.uk,
Dominik Brodowski <linux@dominikbrodowski.net>,
davej@redhat.com
Subject: Re: [PATCH] transition latency of speedstep-ich (third try)
Date: Tue, 29 Nov 2005 00:35:07 +0100 [thread overview]
Message-ID: <438B942B.2090100@tremplin-utc.net> (raw)
In-Reply-To: <88056F38E9E48644A0F562A38C64FB600671185B@scsmsx403.amr.corp.intel.com>
28.11.2005 23:19, Pallipadi, Venkatesh wrote/a écrit:
>>-----Original Message-----
>>From: Mattia Dongili [mailto:malattia@linux.it]
>>
>>I just build speedstep-ich with transition_latency = 250
>>I'll let you know how it goes. Are you interested?
Actually, the ondemand governor is quite safe on this side and multiply
this value by 1000, so it shouldn't bring any problem anyway :-)
>>Maybe it's already been discussed, but how bad would be trying to
>>measure transition latency at runtime?
>>
>
>
>
> Yes. I was thinking the same thing. As this latency may be different on P3-M and P4-M, may be we can do with a measurement at boot time and use it, rather than hardcoding these values. However, I think we will have to do that by using gettimeofday or some such higherlevel call instead of using pmtimer as pmtimer may not be available on all systems at all times. Otherwise, we may end up all sort of pmtimer/pit/hpet timer code in this driver.
>
Sounds interesting :-) Especially as speedstep-ich already does at least
2 frequency transitions while initialising, it should be fairly easy to
implement. I'm more concerned about the time measurement. What could be
done is to use gettimeofday() and check that the result is reasonable
(not too big nor too small), if it's not we just put something
conservative, like 500us.
Eric
next prev parent reply other threads:[~2005-11-28 23:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-28 22:19 [PATCH] transition latency of speedstep-ich (third try) Pallipadi, Venkatesh
2005-11-28 23:35 ` Eric Piel [this message]
2005-11-28 23:48 ` Mattia Dongili
2005-11-29 7:48 ` Mattia Dongili
-- strict thread matches above, loose matches on Subject: below --
2005-10-05 20:39 Pallipadi, Venkatesh
2005-11-26 22:40 ` Eric Piel
2005-11-28 22:12 ` Mattia Dongili
2005-09-28 23:53 Pallipadi, Venkatesh
2005-09-29 22:06 ` Eric Piel
2005-10-14 15:19 ` Stefan Seyfried
2005-09-28 1:26 Pallipadi, Venkatesh
2005-09-28 21:38 ` Eric Piel
2005-02-06 22:33 [PATCH] support for CPUFREQ_ETERNAL drivers by the ondemand governor Eric Piel
2005-02-09 19:15 ` Dominik Brodowski
2005-03-06 17:06 ` [PATCH] transition latency of speedstep-ich Eric Piel
[not found] ` <20050307182137.GB24559@isilmar.linta.de>
[not found] ` <432DD8DD.3090805@tremplin-utc.net>
[not found] ` <20050919101843.GA13041@isilmar.linta.de>
2005-09-19 22:35 ` [PATCH] transition latency of speedstep-ich (third try) 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=438B942B.2090100@tremplin-utc.net \
--to=eric.piel@tremplin-utc.net \
--cc=cpufreq@lists.linux.org.uk \
--cc=davej@redhat.com \
--cc=linux@dominikbrodowski.net \
--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