From: john.stultz@linaro.org (John Stultz)
To: linux-arm-kernel@lists.infradead.org
Subject: One of these things (CONFIG_HZ) is not like the others..
Date: Mon, 21 Jan 2013 16:51:58 -0800 [thread overview]
Message-ID: <50FDE2AE.8030608@linaro.org> (raw)
In-Reply-To: <CAKGA1bmtTH1N8nx79MGiMighdQROpNtpvAZXhHKT+mT3kcazBQ@mail.gmail.com>
On 01/21/2013 02:54 PM, Matt Sealey wrote:
> On Mon, Jan 21, 2013 at 4:36 PM, John Stultz <john.stultz@linaro.org> wrote:
>> On 01/21/2013 01:14 PM, Matt Sealey wrote:
>>> My question really has to be is CONFIG_SCHED_HRTICK useful, what
>>> exactly is it going to do on ARM here since nobody can ever have
>>> enabled it? Is it going to keel over and explode if nobody registers a
>>> non-jiffies sched_clock (since the jiffies clock is technically
>>> reporting itself as a ridiculously high resolution clocksource..)?
>> ??? Not following this at all. jiffies is the *MOST* coarse resolution
>> clocksource there is (at least that I'm aware of.. I recall someone wanting
>> to do a 60Hz clocksource, but I don't think that ever happened).
> Is that based on it's clocksource rating (probably worse than a real
> hrtimer) or it's reported resolution? Because on i.MX51 if I force it
> to use the jiffies clock the debug on the kernel log is telling me it
> has a higher resolution (it TELLS me that it ticks "as fast" as the
> CPU frequency and wraps less than my real timer).
So the clocksource rating is supposed to be defined by the clocksource
driver writer, and just provides a way for the clocksource core to
select the best clocksource given a set of clocksources. It is not
defined as any sort of calculated mapping to any property of the
clocksource itself (although some driver writers might compute a ratings
value in that way, but I feel the static ranking is much simpler). The
comment above struct clocksource in clocksource.h tries to explain this.
As far as jiffies rating, from jiffies.c:
.rating = 1, /* lowest valid rating*/
So I'm not sure what you mean by "the debug on the kernel log is telling
me it has a higher resolution".
> I know where the 60Hz clocksource might come from, the old Amiga
> platforms have one based on the PSU frequency (50Hz in Europe, 60Hz
> US/Japan). Even a 60Hz clocksource is useful though (on the Amiga, at
> least, it is precisely the vsync clock for synchronizing your display
> output on TV-out, which makes it completely useful for the framebuffer
> driver), but.. you just won't expect to assign it as sched_clock or
> your delay timer. And if anyone does I'd expect they'd know full well
> it'd not run so well.
Yes, in the case I was remembering, the 60HZ was driven by the
electrical line.
thanks
-john
WARNING: multiple messages have this Message-ID (diff)
From: John Stultz <john.stultz@linaro.org>
To: Matt Sealey <matt@genesi-usa.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Linux ARM Kernel ML <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>
Subject: Re: One of these things (CONFIG_HZ) is not like the others..
Date: Mon, 21 Jan 2013 16:51:58 -0800 [thread overview]
Message-ID: <50FDE2AE.8030608@linaro.org> (raw)
In-Reply-To: <CAKGA1bmtTH1N8nx79MGiMighdQROpNtpvAZXhHKT+mT3kcazBQ@mail.gmail.com>
On 01/21/2013 02:54 PM, Matt Sealey wrote:
> On Mon, Jan 21, 2013 at 4:36 PM, John Stultz <john.stultz@linaro.org> wrote:
>> On 01/21/2013 01:14 PM, Matt Sealey wrote:
>>> My question really has to be is CONFIG_SCHED_HRTICK useful, what
>>> exactly is it going to do on ARM here since nobody can ever have
>>> enabled it? Is it going to keel over and explode if nobody registers a
>>> non-jiffies sched_clock (since the jiffies clock is technically
>>> reporting itself as a ridiculously high resolution clocksource..)?
>> ??? Not following this at all. jiffies is the *MOST* coarse resolution
>> clocksource there is (at least that I'm aware of.. I recall someone wanting
>> to do a 60Hz clocksource, but I don't think that ever happened).
> Is that based on it's clocksource rating (probably worse than a real
> hrtimer) or it's reported resolution? Because on i.MX51 if I force it
> to use the jiffies clock the debug on the kernel log is telling me it
> has a higher resolution (it TELLS me that it ticks "as fast" as the
> CPU frequency and wraps less than my real timer).
So the clocksource rating is supposed to be defined by the clocksource
driver writer, and just provides a way for the clocksource core to
select the best clocksource given a set of clocksources. It is not
defined as any sort of calculated mapping to any property of the
clocksource itself (although some driver writers might compute a ratings
value in that way, but I feel the static ranking is much simpler). The
comment above struct clocksource in clocksource.h tries to explain this.
As far as jiffies rating, from jiffies.c:
.rating = 1, /* lowest valid rating*/
So I'm not sure what you mean by "the debug on the kernel log is telling
me it has a higher resolution".
> I know where the 60Hz clocksource might come from, the old Amiga
> platforms have one based on the PSU frequency (50Hz in Europe, 60Hz
> US/Japan). Even a 60Hz clocksource is useful though (on the Amiga, at
> least, it is precisely the vsync clock for synchronizing your display
> output on TV-out, which makes it completely useful for the framebuffer
> driver), but.. you just won't expect to assign it as sched_clock or
> your delay timer. And if anyone does I'd expect they'd know full well
> it'd not run so well.
Yes, in the case I was remembering, the 60HZ was driven by the
electrical line.
thanks
-john
next prev parent reply other threads:[~2013-01-22 0:51 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-21 20:01 One of these things (CONFIG_HZ) is not like the others Matt Sealey
2013-01-21 20:01 ` Matt Sealey
2013-01-21 20:41 ` Arnd Bergmann
2013-01-21 20:41 ` Arnd Bergmann
2013-01-21 21:00 ` John Stultz
2013-01-21 21:00 ` John Stultz
2013-01-21 21:12 ` Russell King - ARM Linux
2013-01-21 21:12 ` Russell King - ARM Linux
2013-01-21 22:18 ` John Stultz
2013-01-21 22:18 ` John Stultz
2013-01-21 22:44 ` Russell King - ARM Linux
2013-01-21 22:44 ` Russell King - ARM Linux
2013-01-22 8:27 ` Arnd Bergmann
2013-01-22 8:27 ` Arnd Bergmann
2013-01-21 22:20 ` Matt Sealey
2013-01-21 22:20 ` Matt Sealey
2013-01-21 22:42 ` Russell King - ARM Linux
2013-01-21 22:42 ` Russell King - ARM Linux
2013-01-21 23:23 ` Matt Sealey
2013-01-21 23:23 ` Matt Sealey
2013-01-21 23:49 ` Russell King - ARM Linux
2013-01-21 23:49 ` Russell King - ARM Linux
2013-01-22 0:09 ` Matt Sealey
2013-01-22 0:09 ` Matt Sealey
2013-01-22 0:26 ` Matt Sealey
2013-01-22 0:26 ` Matt Sealey
2013-01-21 21:14 ` Matt Sealey
2013-01-21 21:14 ` Matt Sealey
2013-01-21 22:36 ` John Stultz
2013-01-21 22:36 ` John Stultz
2013-01-21 22:49 ` Russell King - ARM Linux
2013-01-21 22:49 ` Russell King - ARM Linux
2013-01-21 22:54 ` Matt Sealey
2013-01-21 22:54 ` Matt Sealey
2013-01-21 23:13 ` Russell King - ARM Linux
2013-01-21 23:13 ` Russell King - ARM Linux
2013-01-21 23:30 ` Matt Sealey
2013-01-21 23:30 ` Matt Sealey
2013-01-22 0:02 ` Russell King - ARM Linux
2013-01-22 0:02 ` Russell King - ARM Linux
2013-01-22 0:38 ` John Stultz
2013-01-22 0:38 ` John Stultz
2013-01-22 0:51 ` John Stultz [this message]
2013-01-22 0:51 ` John Stultz
2013-01-22 1:06 ` Matt Sealey
2013-01-22 1:06 ` Matt Sealey
2013-01-22 1:18 ` Russell King - ARM Linux
2013-01-22 1:18 ` Russell King - ARM Linux
2013-01-22 1:56 ` Matt Sealey
2013-01-22 1:56 ` Matt Sealey
2013-01-22 1:31 ` John Stultz
2013-01-22 1:31 ` John Stultz
2013-01-22 2:10 ` Matt Sealey
2013-01-22 2:10 ` Matt Sealey
2013-01-31 21:31 ` Thomas Gleixner
2013-01-31 21:31 ` Thomas Gleixner
2013-01-21 21:02 ` Matt Sealey
2013-01-21 21:02 ` Matt Sealey
2013-01-21 22:30 ` Arnd Bergmann
2013-01-21 22:30 ` Arnd Bergmann
2013-01-21 22:45 ` Russell King - ARM Linux
2013-01-21 22:45 ` Russell King - ARM Linux
2013-01-21 23:01 ` Matt Sealey
2013-01-21 23:01 ` Matt Sealey
2013-01-21 21:03 ` Russell King - ARM Linux
2013-01-21 21:03 ` Russell King - ARM Linux
2013-01-21 23:23 ` Tony Lindgren
2013-01-21 23:23 ` Tony Lindgren
2013-01-22 6:23 ` Santosh Shilimkar
2013-01-22 6:23 ` Santosh Shilimkar
2013-01-22 9:31 ` Arnd Bergmann
2013-01-22 9:31 ` Arnd Bergmann
2013-01-22 10:14 ` Santosh Shilimkar
2013-01-22 10:14 ` Santosh Shilimkar
2013-01-22 14:51 ` Russell King - ARM Linux
2013-01-22 14:51 ` Russell King - ARM Linux
2013-01-22 15:05 ` Santosh Shilimkar
2013-01-22 15:05 ` Santosh Shilimkar
2013-01-28 6:08 ` Santosh Shilimkar
2013-01-28 6:08 ` Santosh Shilimkar
2013-01-29 0:01 ` John Stultz
2013-01-29 0:01 ` John Stultz
2013-01-29 6:43 ` Santosh Shilimkar
2013-01-29 6:43 ` Santosh Shilimkar
2013-01-29 10:06 ` Russell King - ARM Linux
2013-01-29 10:06 ` Russell King - ARM Linux
2013-01-29 18:43 ` John Stultz
2013-01-29 18:43 ` John Stultz
2013-01-22 17:31 ` Arnd Bergmann
2013-01-22 17:31 ` Arnd Bergmann
2013-01-22 18:59 ` John Stultz
2013-01-22 18:59 ` John Stultz
2013-01-22 21:52 ` Tony Lindgren
2013-01-22 21:52 ` Tony Lindgren
2013-01-23 5:18 ` Santosh Shilimkar
2013-01-23 5:18 ` Santosh Shilimkar
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=50FDE2AE.8030608@linaro.org \
--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 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.