[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201006094445.09c8b3b9@gandalf.local.home>
Date: Tue, 6 Oct 2020 09:44:45 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: tglx@...utronix.de, mingo@...nel.org, linux-kernel@...r.kernel.org,
bigeasy@...utronix.de, qais.yousef@....com, swood@...hat.com,
valentin.schneider@....com, juri.lelli@...hat.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
bsegall@...gle.com, mgorman@...e.de, bristot@...hat.com,
vincent.donnefort@....com, tj@...nel.org
Subject: Re: [PATCH -v2 15/17] sched: Fix migrate_disable() vs rt/dl
balancing
On Tue, 6 Oct 2020 09:59:39 +0200
Peter Zijlstra <peterz@...radead.org> wrote:
> On Mon, Oct 05, 2020 at 04:57:32PM +0200, Peter Zijlstra wrote:
> > +static inline struct task_struct *get_push_task(struct rq *rq)
> > +{
> > + struct task_struct *p = rq->curr;
> > +
> > + lockdep_assert_held(&rq->lock);
> > +
> > + if (rq->push_busy)
> > + return NULL;
> > +
> > + if (p->nr_cpus_allowed == 1)
> > + return NULL;
>
> This; that means what when we're stuck below a per-cpu thread, we're
> toast. There's just nothing much you can do... :/
Well, hopefully, per CPU threads don't run for long periods of time. I'm
working with folks having issues of running non stop RT threads that every
so often go into the kernel kicking off per CPU kernel threads that now get
starved when the RT tasks go back to user space, causing the rest of the
system to hang.
As I've always said. When dealing with real-time systems, you need to be
careful about how you organize your tasks. Ideally, any RT task that is
pinned to a CPU shouldn't be sharing that CPU with anything else that may
be critical.
-- Steve
>
> > +
> > + rq->push_busy = true;
> > + return get_task_struct(p);
> > +}
Powered by blists - more mailing lists