From: Peter Zijlstra <peterz@infradead.org>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [PATCH 07/10] nohz: Enforce timekeeping on CPU 0
Date: Sat, 19 Jul 2014 20:31:32 +0200 [thread overview]
Message-ID: <20140719183132.GK3935@laptop> (raw)
In-Reply-To: <alpine.LFD.2.11.1407191318320.3647@knanqh.ubzr>
On Sat, Jul 19, 2014 at 01:31:25PM -0400, Nicolas Pitre wrote:
> On Sat, 19 Jul 2014, Frederic Weisbecker wrote:
>
> > The timekeeper gets initialized to the value of the CPU where the
> > first clockevent device is setup. This works well because the timekeeper
> > can be any online CPU in most configs.
> >
> > Full dynticks has its own requirement though and needs the timekeeper
> > to always be 0. And this requirement seem to accomodate pretty well with
> > the above described boot timekeeper setting because the first clockevent
> > device happens to be initialized, most of the time, on the boot CPU
> > (which should be CPU 0).
>
> This might have been discussed before... but this isn't ARM big.LITTLE
> friendly at all.
>
> Could we accommodate for any arbitrary CPU instead of making CPU 0
> "special" other than its role as the boot CPU please? It doesn't have
> to be completely dynamic, but CPU 0 might be a really bad choice for
> ongoing periodic duties in some configurations. For example, we might
> highly prefer to do this on CPU 4 for power efficiency reasons once it
> is online and keep CPU 0 in a deep C-state as much as possible.
This is because CPU0 can be a big core, right? IIRC this is done because
a big core as boot cpu, boots faster and some people think boot time is
relevant.
next prev parent reply other threads:[~2014-07-19 18:31 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-19 0:44 [RFC PATCH 00/10] nohz: Support sysidle (and some more cleanups) Frederic Weisbecker
2014-07-19 0:44 ` [PATCH 01/10] irq_work: Introduce void irq work Frederic Weisbecker
2014-07-21 18:16 ` Paul E. McKenney
2014-07-19 0:44 ` [PATCH 02/10] nohz: Kick full dynticks timer targets with an empty IPI Frederic Weisbecker
2014-07-19 7:19 ` Peter Zijlstra
2014-07-19 13:18 ` Frederic Weisbecker
2014-07-19 13:47 ` Peter Zijlstra
2014-07-19 13:54 ` Frederic Weisbecker
2014-07-19 0:44 ` [PATCH 03/10] rcu: Kick full dynticks CPU on extended grace period with a void IRQ Frederic Weisbecker
2014-07-21 18:16 ` Paul E. McKenney
2014-07-19 0:44 ` [PATCH 04/10] nohz: Appropriate timekeeper kick on sysidle break Frederic Weisbecker
2014-07-21 18:15 ` Paul E. McKenney
2014-07-19 0:44 ` [PATCH 05/10] smp: Fast path check on IPI list Frederic Weisbecker
2014-07-19 0:44 ` [PATCH 06/10] nohz: Define meaningful symbol for nohz full timekeeper Frederic Weisbecker
2014-07-21 18:11 ` Paul E. McKenney
2014-07-21 18:12 ` Paul E. McKenney
2014-07-25 21:27 ` Frederic Weisbecker
2014-07-19 0:44 ` [PATCH 07/10] nohz: Enforce timekeeping on CPU 0 Frederic Weisbecker
2014-07-19 17:31 ` Nicolas Pitre
2014-07-19 18:31 ` Peter Zijlstra [this message]
2014-07-19 18:46 ` Nicolas Pitre
2014-07-19 19:45 ` Peter Zijlstra
2014-07-20 1:07 ` Frederic Weisbecker
2014-07-19 0:44 ` [PATCH 08/10] nohz: Fetch timekeeping max deferment only for timekeeper Frederic Weisbecker
2014-07-19 0:44 ` [PATCH 09/10] nohz: Switch nohz full timekeeper to dynticks idle on top of sysidle detection Frederic Weisbecker
2014-07-21 17:50 ` Paul E. McKenney
2014-07-19 0:44 ` [PATCH 10/10] nohz: Warn on illegal timekeeper switch in nohz full Frederic Weisbecker
2014-07-21 17:51 ` Paul E. McKenney
-- strict thread matches above, loose matches on Subject: below --
2014-07-28 17:37 [PATCH 00/10] nohz: Support sysidle (+ some more nohz kick cleanups) Frederic Weisbecker
2014-07-28 17:37 ` [PATCH 07/10] nohz: Enforce timekeeping on CPU 0 Frederic Weisbecker
2014-07-29 12:12 ` Peter Zijlstra
2014-07-30 13:23 ` Frederic Weisbecker
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=20140719183132.GK3935@laptop \
--to=peterz@infradead.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=viresh.kumar@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox