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
next prev parent reply other threads:[~2012-11-08 21:28 UTC|newest]
Thread overview: 22+ 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 13:46 ` Shawn Guo
2012-11-05 16:09 ` Stanislav Meduna
2012-11-05 22:28 ` Russell King - ARM Linux
2012-11-06 2:40 ` Shawn Guo
2012-11-06 10:12 ` Russell King - ARM Linux
2012-11-06 13:49 ` Shawn Guo
2012-11-06 20:04 ` Russell King - ARM Linux
2012-11-06 8:34 ` scheduler clock for MXS Stanislav Meduna
2012-11-06 9:45 ` Russell King - ARM Linux
2012-11-06 13:46 ` Shawn Guo
2012-11-06 20:20 ` Russell King - ARM Linux
2012-11-06 22:30 ` Stanislav Meduna
2012-11-06 22:46 ` Russell King - ARM Linux
2012-11-07 7:13 ` Shawn Guo
2012-11-08 21:27 ` Stanislav Meduna [this message]
2012-11-08 22:11 ` Russell King - ARM Linux
2012-11-08 22:45 ` [PATCH] ARM: mxs: Setup scheduler clock Stanislav Meduna
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 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).