linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: john.stultz@linaro.org (John Stultz)
To: linux-arm-kernel@lists.infradead.org
Subject: [patch 2/7] clocksource: Get rid of the hardcoded 5 seconds sleep time limit
Date: Wed, 18 May 2011 17:57:35 -0700	[thread overview]
Message-ID: <1305766655.2915.187.camel@work-vm> (raw)
In-Reply-To: <20110518210136.109811585@linutronix.de>

On Wed, 2011-05-18 at 21:33 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (clocksource-make-shift-mult-calc-more-clever.patch)
> Slow clocksources can have a way longer sleep time than 5 seconds and
> even fast ones can easily cope with 600 seconds and still maintain
> proper accuracy.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>  kernel/time/clocksource.c |   38 +++++++++++++++++++-------------------
>  1 file changed, 19 insertions(+), 19 deletions(-)
> 
> Index: linux-2.6-tip/kernel/time/clocksource.c
> ===================================================================
> --- linux-2.6-tip.orig/kernel/time/clocksource.c
> +++ linux-2.6-tip/kernel/time/clocksource.c
> @@ -626,19 +626,6 @@ static void clocksource_enqueue(struct c
>  	list_add(&cs->list, entry);
>  }
> 
> -
> -/*
> - * Maximum time we expect to go between ticks. This includes idle
> - * tickless time. It provides the trade off between selecting a
> - * mult/shift pair that is very precise but can only handle a short
> - * period of time, vs. a mult/shift pair that can handle long periods
> - * of time but isn't as precise.
> - *
> - * This is a subsystem constant, and actual hardware limitations
> - * may override it (ie: clocksources that wrap every 3 seconds).
> - */
> -#define MAX_UPDATE_LENGTH 5 /* Seconds */
> -
>  /**
>   * __clocksource_updatefreq_scale - Used update clocksource with new freq
>   * @t:		clocksource to be registered
> @@ -652,15 +639,28 @@ static void clocksource_enqueue(struct c
>   */
>  void __clocksource_updatefreq_scale(struct clocksource *cs, u32 scale, u32 freq)
>  {
> +	unsigned long sec;
> +
>  	/*
> -	 * Ideally we want to use  some of the limits used in
> -	 * clocksource_max_deferment, to provide a more informed
> -	 * MAX_UPDATE_LENGTH. But for now this just gets the
> -	 * register interface working properly.
> +	 * Calc the maximum number of seconds which we can run before
> +	 * wrapping around. For clocksources which have a mask > 32bit
> +	 * we need to limit the max sleep time to have a good
> +	 * conversion precision. 10 minutes is still a reasonable
> +	 * amount. That results in a shift value of 24 for a
> +	 * clocksource with mask >= 40bit and f >= 4GHz. That maps to
> +	 * ~ 0.06ppm granularity for NTP. We apply the same 12.5%
> +	 * margin as we do in clocksource_max_deferment()
>  	 */

So, its not clear to me that the 12.5% margin really needed, since we
take it out when we calculate clocksource_max_deferment(). Although with
or without the margin I get the same mult/shift/max_idle_ns values for
the hardware I'm testing.

Another nice detail from the change: It doesn't affect clocksources that
normally wrap quickly:

Without your patch:
--------------
JDB: hpet mult: 2684354560 shift: 26 max_idle: 83214991360
JDB: acpi_pm mult: 2343484437 shift: 23 max_idle: 4540500826
JDB: tsc mult: 1342183991 shift: 31 max_idle: 2600481483

With your patch:
---------------
JDB: hpet mult: 2684354560 shift: 26 max_idle: 83214991360
JDB: acpi_pm mult: 2343484437 shift: 23 max_idle: 4540500826
JDB: tsc mult: 10485812 shift: 24 max_idle: 332861616128

Although interestingly 332 secs calculated for the max idle is more then
12% off of 600.

> +	sec = (cs->mask - (cs->mask >> 5));
> +	do_div(sec, freq);
> +	do_div(sec, scale);
> +	if (!sec)
> +		sec = 1;
> +	else if (sec > 600 && cs->mask > UINT_MAX)
> +		sec = 600;
> +
>  	clocks_calc_mult_shift(&cs->mult, &cs->shift, freq,
> -				      NSEC_PER_SEC/scale,
> -				      MAX_UPDATE_LENGTH*scale);
> +			       NSEC_PER_SEC / scale, sec * scale);
>  	cs->max_idle_ns = clocksource_max_deferment(cs);
>  }
>  EXPORT_SYMBOL_GPL(__clocksource_updatefreq_scale);

Overall it looks good. I'm doing some NTP testing with the TSC shift
change to make sure we don't get any odd side effects. I'll let you know
how those go.

thanks
-john

  reply	other threads:[~2011-05-19  0:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-18 21:33 [patch 0/7] clocksources/clockevents improvements Thomas Gleixner
2011-05-18 21:33 ` [patch 2/7] clocksource: Get rid of the hardcoded 5 seconds sleep time limit Thomas Gleixner
2011-05-19  0:57   ` John Stultz [this message]
2011-05-19  8:43     ` Thomas Gleixner
2011-05-20  1:10     ` john stultz
2011-05-18 21:33 ` [patch 1/7] clocksource: Restructure clocksource struct members Thomas Gleixner
2011-05-18 21:33 ` [patch 3/7] clockevents: Restructure clock_event_device members Thomas Gleixner
2011-05-18 21:33 ` [patch 4/7] clockevents: Provide combined configure and register function Thomas Gleixner
2011-05-19  9:08   ` Ingo Molnar
2011-05-19 10:00     ` Thomas Gleixner
2011-05-19 18:10       ` Ingo Molnar
2011-05-18 21:33 ` [patch 6/7] x86: Convert PIT to clockevents_config_and_register() Thomas Gleixner
2011-05-18 21:33 ` [patch 5/7] clockevents: Provide interface to reconfigure an active clock event device Thomas Gleixner
2011-05-19  7:26   ` Linus Walleij
2011-05-19  9:10   ` Ingo Molnar
2011-05-19  9:33     ` Thomas Gleixner
2011-05-19  9:37       ` Ingo Molnar
2011-05-18 21:33 ` [patch 7/7] x86: hpet: Cleanup the clockevents init and register code Thomas Gleixner
2011-05-19  9:33   ` Ingo Molnar
2011-05-19  9:34 ` [patch 0/7] clocksources/clockevents improvements Ingo Molnar

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=1305766655.2915.187.camel@work-vm \
    --to=john.stultz@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).