linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: One of these things (CONFIG_HZ) is not like the others..
Date: Mon, 21 Jan 2013 16:38:43 -0800	[thread overview]
Message-ID: <50FDDF93.5030407@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:
>>> Or is this one of those things that if your platform doesn't have a
>>> real high resolution timer, you shouldn't enable HRTIMERS and
>>> therefore not enable SCHED_HRTICK as a result? That affects
>>> ARCH_MULTIPLATFORM here. Is the solution as simple as
>>> ARCH_MULTIPLATFORM compliant platforms kind of have to have a high
>>> resolution timer? Documentation to that effect?
>> SO HRITMERS was designed to be be build time enabled, while still giving you
>> a functioning system if it was booted on a system that didn't support
>> clockevents.  We boot with standard HZ, and only switch over to HRT mode if
>> we have a proper clocksource and clockevent driver.
> Okay. I'm still a little confused as to what SCHED_HRTICK actually
> makes a difference to, though.
>
>  From that description, we are booting with standard HZ on ARM, and the
> core sched_clock (as in we can call setup_sched_clock)
> and/or/both/optionally using a real delay_timer switch to HRT mode if
> we have the right equipment available in the kernel and at runtime on
> the SoC.. but the process scheduler isn't compiled with the means to
> actually take advantage of us being in HRT mode?

So I'm actually not super familiar with SCHED_HRTICK details, but from 
my brief skim of it it looks like its useful for turning off the 
periodic timer tick, and allowing the scheduler tick to be triggered by 
an hrtimer itself (There's a number of these interesting inversions that 
go on in switching to HRT mode - for instance, standard timer ticks are 
switched to being hrtimer events themselves).

This likely has the benefit of time-accurate preemption (well, long 
term, as if the timer granularity isn't matching you could be delayed up 
to a tick - but it wouldn't drift).

I'm guessing Thomas would probably know best what the potential issues 
would be from running ((CONFIG_HRTIMER  || CONFIG_NO_HZ) && 
!CONFIG_SCHED_HRTICK).

thanks
-john

  parent reply	other threads:[~2013-01-22  0:38 UTC|newest]

Thread overview: 48+ 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:41 ` Arnd Bergmann
2013-01-21 21:00   ` John Stultz
2013-01-21 21:12     ` Russell King - ARM Linux
2013-01-21 22:18       ` John Stultz
2013-01-21 22:44         ` Russell King - ARM Linux
2013-01-22  8:27           ` Arnd Bergmann
2013-01-21 22:20       ` Matt Sealey
2013-01-21 22:42         ` Russell King - ARM Linux
2013-01-21 23:23           ` Matt Sealey
2013-01-21 23:49             ` Russell King - ARM Linux
2013-01-22  0:09               ` Matt Sealey
2013-01-22  0:26                 ` Matt Sealey
2013-01-21 21:14     ` Matt Sealey
2013-01-21 22:36       ` John Stultz
2013-01-21 22:49         ` Russell King - ARM Linux
2013-01-21 22:54         ` Matt Sealey
2013-01-21 23:13           ` Russell King - ARM Linux
2013-01-21 23:30             ` Matt Sealey
2013-01-22  0:02               ` Russell King - ARM Linux
2013-01-22  0:38           ` John Stultz [this message]
2013-01-22  0:51           ` John Stultz
2013-01-22  1:06             ` Matt Sealey
2013-01-22  1:18               ` Russell King - ARM Linux
2013-01-22  1:56                 ` Matt Sealey
2013-01-22  1:31               ` John Stultz
2013-01-22  2:10                 ` Matt Sealey
2013-01-31 21:31                   ` Thomas Gleixner
2013-01-21 21:02   ` Matt Sealey
2013-01-21 22:30     ` Arnd Bergmann
2013-01-21 22:45       ` Russell King - ARM Linux
2013-01-21 23:01         ` Matt Sealey
2013-01-21 21:03   ` Russell King - ARM Linux
2013-01-21 23:23     ` Tony Lindgren
2013-01-22  6:23       ` Santosh Shilimkar
2013-01-22  9:31         ` Arnd Bergmann
2013-01-22 10:14           ` Santosh Shilimkar
2013-01-22 14:51             ` Russell King - ARM Linux
2013-01-22 15:05               ` Santosh Shilimkar
2013-01-28  6:08                 ` Santosh Shilimkar
2013-01-29  0:01                   ` John Stultz
2013-01-29  6:43                     ` Santosh Shilimkar
2013-01-29 10:06                       ` Russell King - ARM Linux
2013-01-29 18:43                       ` John Stultz
2013-01-22 17:31               ` Arnd Bergmann
2013-01-22 18:59               ` John Stultz
2013-01-22 21:52                 ` Tony Lindgren
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=50FDDF93.5030407@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=matt@genesi-usa.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.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).