From: Eric Piel <Eric.Piel@tremplin-utc.net>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: davej@redhat.com, Dominik Brodowski <linux@dominikbrodowski.net>,
cpufreq@lists.linux.org.uk
Subject: Re: [PATCH] transition latency of speedstep-ich (third try)
Date: Wed, 28 Sep 2005 23:38:14 +0200 [thread overview]
Message-ID: <433B0D46.7010907@tremplin-utc.net> (raw)
In-Reply-To: <88056F38E9E48644A0F562A38C64FB6005D88D3D@scsmsx403.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2917 bytes --]
28.09.2005 03:26, Pallipadi, Venkatesh wrote/a écrit:
>
> Great work! Getting those useful numbers form those documents :).
>
> I think the 100uS and 50uS looks proper from what the documents describe. However, there is one factor that we are missing though. Speedstep-ich uses IO ports to initiate these transitions. Right? These IO port accesses trap into BIOS code which actually initiaites the trasntion. And this trap into BIOS code happens through SMM. And whenvever SMM's are involved I have seen latencies of upto 500uS! And in speedstep_ich:speedstep_set_state(), I see more than one in/out instructions. So, it can easily be higher than this.
It's great to know that I've managed to read in between the line of the
intel documents succesfully ;-)
>
> I think we need to add a guestimate for SMM latency number as well.
>
> Eric,
> Can you put rdtsc's around these in/out on your system and check how long do they really take. On P4M, rdtsc should be running all the time other than the Cpu being in deep_sleep state. That should give us some idea about the SMM latency.
>
Ok, I've just done it. It's on a P3 coppermine though (not a P4M). So
I've measure the difference of tsc before and after the in/out
instructions (not included the local_irq_*()). The patch is attached for
double check (or if someone wants to try on another CPU). The values
seem very small compare to the 500uS you mentioned.
After few minutes with ondemand governor, there was a log like this:
Sep 28 23:30:32 circle kernel: cpufreq transition took 4862 cycles
Sep 28 23:30:33 circle kernel: cpufreq transition took 4473 cycles
Sep 28 23:30:33 circle kernel: cpufreq transition took 4836 cycles
Sep 28 23:30:35 circle kernel: cpufreq transition took 4723 cycles
Sep 28 23:30:35 circle kernel: cpufreq transition took 5640 cycles
Sep 28 23:30:48 circle kernel: cpufreq transition took 4515 cycles
Sep 28 23:30:48 circle kernel: cpufreq transition took 4904 cycles
Sep 28 23:31:02 circle kernel: cpufreq transition took 4286 cycles
Sep 28 23:31:02 circle kernel: cpufreq transition took 4607 cycles
Sep 28 23:31:03 circle kernel: cpufreq transition took 4279 cycles
Sep 28 23:31:03 circle kernel: cpufreq transition took 4605 cycles
Sep 28 23:31:04 circle kernel: cpufreq transition took 4694 cycles
Sep 28 23:31:04 circle kernel: cpufreq transition took 4605 cycles
Sep 28 23:31:13 circle kernel: cpufreq transition took 4683 cycles
Sep 28 23:31:14 circle kernel: cpufreq transition took 4676 cycles
Sep 28 23:31:14 circle kernel: cpufreq transition took 4515 cycles
Sep 28 23:31:15 circle kernel: cpufreq transition took 4522 cycles
Maximum I've seen is 5640 cycles, minimum is about 4200c. My CPU is
clocked 1GHz so the result can be easily summarized to a maximum of
about 6uS.
As it's very different from the numbers you got, I wonder if I mistook
somewhere ?
Eric
[-- Attachment #2: speedstep-ich-measure-transition-2.6.13.patch --]
[-- Type: text/x-patch, Size: 981 bytes --]
--- arch/i386/kernel/cpu/cpufreq/speedstep-ich.c-beforetsc 2005-09-28 23:23:49.000000000 +0200
+++ arch/i386/kernel/cpu/cpufreq/speedstep-ich.c 2005-09-28 23:23:18.000000000 +0200
@@ -66,6 +66,7 @@ static void speedstep_set_state (unsigne
u8 pm2_blk;
u8 value;
unsigned long flags;
+ unsigned long long tsc1, tsc2;
if (!speedstep_chipset_dev || (state > 0x1))
return;
@@ -86,6 +87,8 @@ static void speedstep_set_state (unsigne
/* Disable IRQs */
local_irq_save(flags);
+ rdtscll(tsc1);
+
/* read state */
value = inb(pmbase + 0x50);
@@ -111,6 +114,8 @@ static void speedstep_set_state (unsigne
/* check if transition was successful */
value = inb(pmbase + 0x50);
+
+ rdtscll(tsc2);
/* Enable IRQs */
local_irq_restore(flags);
@@ -123,6 +128,7 @@ static void speedstep_set_state (unsigne
printk (KERN_ERR "cpufreq: change failed - I/O error\n");
}
+ printk(KERN_ERR "cpufreq transition took %llu cycles\n", tsc2 - tsc1);
return;
}
[-- Attachment #3: Type: text/plain, Size: 147 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq
next prev parent reply other threads:[~2005-09-28 21:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-28 1:26 [PATCH] transition latency of speedstep-ich (third try) Pallipadi, Venkatesh
2005-09-28 21:38 ` Eric Piel [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-11-28 22:19 Pallipadi, Venkatesh
2005-11-28 23:35 ` Eric Piel
2005-11-28 23:48 ` Mattia Dongili
2005-11-29 7:48 ` Mattia Dongili
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-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=433B0D46.7010907@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