All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.