All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Meduna <stano@meduna.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Shawn Guo <shawn.guo@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: scheduler clock for MXS
Date: Thu, 08 Nov 2012 22:27:59 +0100	[thread overview]
Message-ID: <509C23DF.1020106@meduna.org> (raw)
In-Reply-To: <20121106224624.GR28327@n2100.arm.linux.org.uk>

On 06.11.2012 23:46, Russell King - ARM Linux wrote:

>  * round_jiffies - function to round jiffies to a full second
> 
> This is probably it.  With mine, it's a 32.768kHz clock, so limiting
> it to 16-bit gives a wrap period of 2 seconds exactly.  We take 10%
> off, so the timer would be asked to fire every 1.8s, which would be
> rounded up to 2 seconds.  That's a little too close for comfort...

Confirmed.

- if I artificially change my timer code to act as a 16-bit one,
  I get wrap-arounds. Not always, but there are definitely some
  during the bootup (where maybe the tick is sometimes delayed
  a tad more)

- if I then remove the round_jiffies and only leave jiffies +
  wrap_ticks, the wrap-arounds go away

> I think in this case, we need a version of round_jiffies() which _always_
> rounds down.  Unfortunately, it doesn't exist.  Thomas?  What are the
> options here?

What is actually the reason of round_jiffies there? The
http://kernel.org/doc/htmldocs/device-drivers/API-round-jiffies.html
mentions saving power, is it the only one?

I'd probably just leave the round_jiffies out at least for
wrap_ticks < around 16*HZ. Above that the error by possibly
rounding up can be ignored.

There is also a round_jiffies_up - unless I am too tired, as long as
we tick no faster than once per second, subtracting (HZ-1) and rounding
up should be the same as rounding down.

But: is the round_jiffies* safe at all for sub-second precision
at jiffies around 0xffffffff? From quick looking it does a modulo,
0xffffffff % say 250 is 45, the next jiffy is at 0...

Regards
-- 
                                       Stano


WARNING: multiple messages have this Message-ID (diff)
From: stano@meduna.org (Stanislav Meduna)
To: linux-arm-kernel@lists.infradead.org
Subject: scheduler clock for MXS
Date: Thu, 08 Nov 2012 22:27:59 +0100	[thread overview]
Message-ID: <509C23DF.1020106@meduna.org> (raw)
In-Reply-To: <20121106224624.GR28327@n2100.arm.linux.org.uk>

On 06.11.2012 23:46, Russell King - ARM Linux wrote:

>  * round_jiffies - function to round jiffies to a full second
> 
> This is probably it.  With mine, it's a 32.768kHz clock, so limiting
> it to 16-bit gives a wrap period of 2 seconds exactly.  We take 10%
> off, so the timer would be asked to fire every 1.8s, which would be
> rounded up to 2 seconds.  That's a little too close for comfort...

Confirmed.

- if I artificially change my timer code to act as a 16-bit one,
  I get wrap-arounds. Not always, but there are definitely some
  during the bootup (where maybe the tick is sometimes delayed
  a tad more)

- if I then remove the round_jiffies and only leave jiffies +
  wrap_ticks, the wrap-arounds go away

> I think in this case, we need a version of round_jiffies() which _always_
> rounds down.  Unfortunately, it doesn't exist.  Thomas?  What are the
> options here?

What is actually the reason of round_jiffies there? The
http://kernel.org/doc/htmldocs/device-drivers/API-round-jiffies.html
mentions saving power, is it the only one?

I'd probably just leave the round_jiffies out at least for
wrap_ticks < around 16*HZ. Above that the error by possibly
rounding up can be ignored.

There is also a round_jiffies_up - unless I am too tired, as long as
we tick no faster than once per second, subtracting (HZ-1) and rounding
up should be the same as rounding down.

But: is the round_jiffies* safe at all for sub-second precision
at jiffies around 0xffffffff? From quick looking it does a modulo,
0xffffffff % say 250 is 45, the next jiffy is@0...

Regards
-- 
                                       Stano

  parent reply	other threads:[~2012-11-08 21:28 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-31 21:41 Wakeup latency measured with SCHED_TRACER depends on HZ Stanislav Meduna
2012-11-02 14:29 ` Stanislav Meduna
2012-11-05  2:57   ` Shawn Guo
2012-11-05  9:14     ` scheduler clock for MXS [Was: Re: Wakeup latency measured with SCHED_TRACER depends on HZ] Stanislav Meduna
2012-11-05  9:14       ` Stanislav Meduna
2012-11-05 13:46       ` Shawn Guo
2012-11-05 13:46         ` Shawn Guo
2012-11-05 16:09         ` Stanislav Meduna
2012-11-05 16:09           ` Stanislav Meduna
2012-11-05 22:28           ` Russell King - ARM Linux
2012-11-05 22:28             ` Russell King - ARM Linux
2012-11-06  2:40             ` Shawn Guo
2012-11-06  2:40               ` Shawn Guo
2012-11-06 10:12               ` Russell King - ARM Linux
2012-11-06 10:12                 ` Russell King - ARM Linux
2012-11-06 13:49                 ` Shawn Guo
2012-11-06 13:49                   ` Shawn Guo
2012-11-06 20:04                   ` Russell King - ARM Linux
2012-11-06 20:04                     ` Russell King - ARM Linux
2012-11-06  8:34             ` scheduler clock for MXS Stanislav Meduna
2012-11-06  8:34               ` Stanislav Meduna
2012-11-06  9:45               ` Russell King - ARM Linux
2012-11-06  9:45                 ` Russell King - ARM Linux
2012-11-06 13:46               ` Shawn Guo
2012-11-06 13:46                 ` Shawn Guo
2012-11-06 20:20                 ` Russell King - ARM Linux
2012-11-06 20:20                   ` Russell King - ARM Linux
2012-11-06 22:30                   ` Stanislav Meduna
2012-11-06 22:30                     ` Stanislav Meduna
2012-11-06 22:46                     ` Russell King - ARM Linux
2012-11-06 22:46                       ` Russell King - ARM Linux
2012-11-07  7:13                       ` Shawn Guo
2012-11-07  7:13                         ` Shawn Guo
2012-11-08 21:27                       ` Stanislav Meduna [this message]
2012-11-08 21:27                         ` Stanislav Meduna
2012-11-08 22:11                         ` Russell King - ARM Linux
2012-11-08 22:11                           ` Russell King - ARM Linux
2012-11-08 22:45                 ` [PATCH] ARM: mxs: Setup scheduler clock Stanislav Meduna
2012-11-08 22:45                   ` Stanislav Meduna
2012-11-12  1:54                   ` Shawn Guo
2012-11-12  1:54                     ` Shawn Guo

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=509C23DF.1020106@meduna.org \
    --to=stano@meduna.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=shawn.guo@linaro.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.