All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-rt-users <linux-rt-users@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>, Daniel Wagner <wagi@monom.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] sched/rt: Do not do push/pull when there is only one CPU
Date: Sat, 2 Dec 2017 14:55:55 +0100	[thread overview]
Message-ID: <20171202135555.GW3326@worktop> (raw)
In-Reply-To: <20171202125330.xrxspjeedbpr4hk5@linutronix.de>

On Sat, Dec 02, 2017 at 01:53:31PM +0100, Sebastian Andrzej Siewior wrote:
> On 2017-12-01 13:32:22 [-0500], Steven Rostedt wrote:
> > 
> > Daniel Wagner reported a crash on the beaglebone black. This is a
> > single CPU architecture, and does not have a functional:
> > arch_send_call_function_single_ipi() and can crash if that is called.
> > 
> > As it only has one CPU, it shouldn't be called, but if the kernel is
> > compiled for SMP, the push/pull RT scheduling logic now calls it for
> > irq_work if the one CPU is overloaded, it can use that function to call
> > itself and crash the kernel.
> > 
> > There's no reason for the push/pull logic to even be called if there's
> > only one CPU online. Have it bail if it sees that's the case.
> > 
> > Link: http://lkml.kernel.org/r/8c913cc2-b2e3-8c2e-e503-aff1428f8ff5@monom.org
> > Fixes: 4bdced5c9 ("sched/rt: Simplify the IPI based RT balancing logic")
> > Cc: stable@vger.kernel.org
> > Reported-by: Daniel Wagner <wagi@monom.org>
> > ---
> > diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> > index 4056c19ca3f0..50d2f8179f70 100644
> > --- a/kernel/sched/rt.c
> > +++ b/kernel/sched/rt.c
> > @@ -1784,6 +1784,10 @@ static int push_rt_task(struct rq *rq)
> >  	if (!rq->rt.overloaded)
> >  		return 0;
> >  
> > +	/* If we are the only CPU, don't bother */
> > +	if (num_online_cpus() == 1)
> > +		return 0;
> > +
> 
> what about a check next to sched_feat(RT_PUSH_IPI)? I don't know if this
> is a hot path or not (due to bitmap_weight). If it is, then I would
> suggest something like a jump-label which is enabled if more than one
> CPU has been enabled on boot.

Yeah good point; bitmap_weight can be quite expensive.

  reply	other threads:[~2017-12-02 13:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-01 18:32 [PATCH] sched/rt: Do not do push/pull when there is only one CPU Steven Rostedt
2017-12-02 12:53 ` Sebastian Andrzej Siewior
2017-12-02 13:55   ` Peter Zijlstra [this message]
2017-12-02 17:12   ` Steven Rostedt
2017-12-02 18:05     ` Steven Rostedt

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=20171202135555.GW3326@worktop \
    --to=peterz@infradead.org \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=wagi@monom.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.