From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Vatika Harlalka <vatikaharlalka@gmail.com>,
Chris Metcalf <cmetcalf@ezchip.com>,
Thomas Gleixner <tglx@linutronix.de>,
Preeti U Murthy <preeti@linux.vnet.ibm.com>,
Christoph Lameter <cl@linux.com>,
"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH RESEND] sched/nohz: Affine unpinned timers to housekeepers
Date: Mon, 24 Aug 2015 03:45:30 +0200 [thread overview]
Message-ID: <20150824014528.GC20044@lerouge> (raw)
In-Reply-To: <20150823054032.GA28133@gmail.com>
On Sun, Aug 23, 2015 at 07:40:32AM +0200, Ingo Molnar wrote:
> So I almost applied this yesterday, but had the following question: what ensures
> that housekeeping_mask isn't empty? If it's empty then housekeeping_any_cpu()
> returns cpumask_any_and() of an empty cpumask - which returns an out of range
> index AFAICS - which will crash and burn in:
>
> kernel/time/hrtimer.c: return &per_cpu(hrtimer_bases, get_nohz_timer_target());
> kernel/time/timer.c: return per_cpu_ptr(&tvec_bases, get_nohz_timer_target());
>
> housekeeping_mask itself is derived from tick_nohz_full_mask (it's the inverse of
> it in essence), and tick_nohz_full_mask is set via two methods, either via a boot
> parameter:
>
> if (cpulist_parse(str, tick_nohz_full_mask) < 0) {
>
> in tick_nohz_full_setup(). What ensures here that tick_nohz_full_mask is not
> completely full - making housekeeping_mask empty?
>
> The other method is via CONFIG_NO_HZ_FULL_ALL:
>
> cpumask_setall(tick_nohz_full_mask);
>
> here it's fully set - triggering the bug I'm worried about. So what am I missing,
> what prevents CONFIG_NO_HZ_FULL_ALL from crashing?
Legitimate worry and I should have explained that in the changelog.
Like Paul replied, we make sure that at least the boot CPU is excluded
from tick_nohz_full_mask in tick_nohz_init(). Then housekeeping_mask,
by reverse effect, contains that boot CPU at least.
And we also make sure that the boot CPU can't get offline
(tick_nohz_cpu_down_callback()).
Now we should really document and check that assumption so here is a
second patch below. The sched patch depends on tip:sched/core (to avoid
conflicts with sched changes) and the following one is based on
tip:timer/nohz but should be applicable to sched/core without conflict.
Both are standalone anyway.
Thanks!
---
From: Frederic Weisbecker <fweisbec@gmail.com>
Date: Sun, 23 Aug 2015 19:34:31 +0200
Subject: [PATCH] nohz: Assert existing housekeepers when nohz full enabled
The code ensures that at least the boot CPU serves as a housekeeper.
Let's assert this assumption to make sure that we have CPUs to handle
unbound jobs like workqueues and timers while nohz full CPUs run
undisturbed.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
---
kernel/time/tick-sched.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 3319e16..cc9884f 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -370,6 +370,12 @@ void __init tick_nohz_init(void)
cpu_notifier(tick_nohz_cpu_down_callback, 0);
pr_info("NO_HZ: Full dynticks CPUs: %*pbl.\n",
cpumask_pr_args(tick_nohz_full_mask));
+
+ /*
+ * We need at least one CPU to handle housekeeping work such
+ * as timekeeping, unbound timers, workqueues, ...
+ */
+ WARN_ON_ONCE(cpumask_empty(housekeeping_mask));
}
#endif
--
2.1.4
prev parent reply other threads:[~2015-08-24 1:45 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-14 1:46 [PATCH RESEND] sched/nohz: Affine unpinned timers to housekeepers Frederic Weisbecker
2015-08-22 21:09 ` Ping: " Frederic Weisbecker
2015-08-23 1:22 ` Christoph Lameter
2015-08-23 5:40 ` Ingo Molnar
2015-08-23 16:01 ` Paul E. McKenney
2015-08-24 1:28 ` Frederic Weisbecker
2015-08-24 6:44 ` Ingo Molnar
2015-08-24 7:23 ` Mike Galbraith
2015-08-24 7:41 ` Ingo Molnar
2015-08-24 7:54 ` Mike Galbraith
2015-08-24 8:00 ` Ingo Molnar
2015-08-24 13:36 ` Frederic Weisbecker
2015-08-24 14:01 ` Mike Galbraith
2015-08-25 8:29 ` Ingo Molnar
2015-08-25 13:45 ` Frederic Weisbecker
2015-08-28 8:32 ` Ingo Molnar
2015-08-28 12:30 ` Frederic Weisbecker
2015-08-24 13:50 ` Paul E. McKenney
2015-08-24 14:04 ` Frederic Weisbecker
2015-08-24 15:45 ` Paul E. McKenney
2015-08-24 1:45 ` Frederic Weisbecker [this message]
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=20150824014528.GC20044@lerouge \
--to=fweisbec@gmail.com \
--cc=cl@linux.com \
--cc=cmetcalf@ezchip.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=preeti@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=vatikaharlalka@gmail.com \
/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.