From: Frederic Weisbecker <fweisbec@gmail.com>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
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: Sun, 20 Jul 2014 03:07:24 +0200 [thread overview]
Message-ID: <20140720010440.GA2062@lerouge> (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.
I can certainly arrange for setting user defined timekeeper on boot
time. Just one constraint: since the timekeeper is fixed, we can't
offline it. That's usually fine with CPU 0 but on other CPUs, rejecting
a CPU offlining blocks the suspend process.
I imagine I can handover the timekeeping to another CPU in this case
and accept the offlining. But there are chances that the only online
CPUs remaining are full dynticks and it's not tempting to give them
a timekeeping duty.
next prev parent reply other threads:[~2014-07-20 1:07 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
2014-07-19 18:46 ` Nicolas Pitre
2014-07-19 19:45 ` Peter Zijlstra
2014-07-20 1:07 ` Frederic Weisbecker [this message]
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=20140720010440.GA2062@lerouge \
--to=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=peterz@infradead.org \
--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