cpufreq Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Piel <Eric.Piel@tremplin-utc.net>
To: Mattia Dongili <malattia@linux.it>
Cc: CPUFreq Mailing List <cpufreq@lists.linux.org.uk>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	davej@redhat.com
Subject: Re: [PATCH 2/2] Measure transition latency at driver initialization
Date: Wed, 30 Nov 2005 12:46:25 +0100	[thread overview]
Message-ID: <438D9111.2000306@tremplin-utc.net> (raw)
In-Reply-To: <11333087111183-git-send-email-malattia@linux.it>

As stated before, the whole idea is probably good, at least it should 
finally get rid of CPUFREQ_ETERNAL transition. BTW, maybe some other 
drivers could benefit of the same approach :-)

However, I disagree a bit with the implementation:
* don't make it a module parameter: either this aproach works and the 
module should always use it or it doesn't. The problem with parameters 
is that only few users will end up using this feature.

* You should add a test to check that the transition measurement didn't 
go wrong. It would be a pitty that a user burns his CPU simply because 
the resolution of gettimeofday() was not good enough ;-) cf in the code

* At initialisation, the driver already changes twice of frequency (in 
speedstep_get_freqs()). No need to change twice more to measure the 
transitions! We should put the time measurement inside 
speedstep_get_freqs() or inside __speedstep_set_state(). Just check if 
transition_latency == CPUFREQ_ETERNAL, if so, do the measurement.

Few more comments below.



11/30/2005 12:58 AM, Mattia Dongili wrote/a écrit:
:
>  
> @@ -128,11 +127,8 @@ static void speedstep_set_state (unsigne
>  	/* check if transition was successful */
>  	value = inb(pmbase + 0x50);
>  
> -	/* Enable IRQs */
> -	local_irq_restore(flags);
> -
>  	dprintk("read at pmbase 0x%x + 0x50 returned 0x%x\n", pmbase, value);
> -
> +	
Watch out not to insert non needed tabs ;-)

:
>  
>  /**
>   * speedstep_activate - activate SpeedStep control in the chipset
> @@ -320,6 +378,7 @@ static int speedstep_cpu_init(struct cpu
>  {
>  	int result = 0;
>  	unsigned int speed;
> +	unsigned int transition_latency = CPUFREQ_ETERNAL;
>  	cpumask_t cpus_allowed;
>  
>  	/* only run on CPU to be set, or on its sibling */
> @@ -334,7 +393,7 @@ static int speedstep_cpu_init(struct cpu
>  	result = speedstep_get_freqs(speedstep_processor,
>  				     &speedstep_freqs[SPEEDSTEP_LOW].frequency,
>  				     &speedstep_freqs[SPEEDSTEP_HIGH].frequency,
> -				     &speedstep_set_state);
> +				     &__speedstep_set_state);
>  	set_cpus_allowed(current, cpus_allowed);
>  	if (result)
>  		return result;
> @@ -348,9 +407,14 @@ static int speedstep_cpu_init(struct cpu
>  		(speed == speedstep_freqs[SPEEDSTEP_LOW].frequency) ? "low" : "high",
>  		(speed / 1000));
>  
> +	if (measure_latency) {
> +		transition_latency = speedstep_measure_latency() * 1000;
> +		dprintk("measured transition latency is %u mS\n", transition_latency);
> +	}
> +	
The measurement was done only once, while transition_latency should be 
the maximum possible. It's safer to multiply the measurement by some 
factor. As we've noticed it's very stable, maybe 120% should be OK:
/*
  * converts from microseconds to nanoseconds and add 20% security margin
  */
transition_latency = speedstep_measure_latency() * 1200;

Additionally, I'd like to see some security test like this:
/* does the measurement seem to have reasonable value ? */
if ((transition_latency > 10000000) || (transition_latency < 50000))
	transition_latency = 500000; /* 500us is a very high guess */

:


cu,
Eric

  reply	other threads:[~2005-11-30 11:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-29 23:58 [RFC][PATCH 0/0] measure speedstep-ich transition latency at CPU initialization Mattia Dongili
2005-11-29 23:58 ` [PATCH 1/2] Move PMBASE reading away and do it only once at initialization time Mattia Dongili
2005-11-29 23:58   ` [PATCH 2/2] Measure transition latency at driver initialization Mattia Dongili
2005-11-30 11:46     ` Eric Piel [this message]
2005-11-30 22:30       ` Mattia Dongili
2005-11-30 23:41         ` Eric Piel
2005-12-01 19:31           ` [PATCH 2/2 updated] " Mattia Dongili
2005-12-01 21:05             ` Eric Piel
2005-12-01 23:34               ` Mattia Dongili
2005-12-02 11:37                 ` Eric Piel
2005-12-02 13:34                   ` Mattia Dongili
2005-12-02 20:59                     ` Mattia Dongili
2005-12-02 23:43                       ` Eric Piel
2005-12-04 17:00                       ` Dominik Brodowski
2005-12-02  4:38               ` Ville Syrjälä
2005-11-30 11:02   ` [PATCH 1/2] Move PMBASE reading away and do it only once at initialization time Eric Piel
2005-11-30 21:00     ` Mattia Dongili
2005-12-04 16:58       ` Dominik Brodowski
  -- strict thread matches above, loose matches on Subject: below --
2005-11-30 23:59 [PATCH 2/2] Measure transition latency at driver initialization 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=438D9111.2000306@tremplin-utc.net \
    --to=eric.piel@tremplin-utc.net \
    --cc=cpufreq@lists.linux.org.uk \
    --cc=davej@redhat.com \
    --cc=linux@dominikbrodowski.net \
    --cc=malattia@linux.it \
    /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