[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181011134224.GT9130@localhost.localdomain>
Date: Thu, 11 Oct 2018 15:42:24 +0200
From: Juri Lelli <juri.lelli@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: luca abeni <luca.abeni@...tannapisa.it>, mingo@...hat.com,
rostedt@...dmis.org, tglx@...utronix.de,
linux-kernel@...r.kernel.org, claudio@...dence.eu.com,
tommaso.cucinotta@...tannapisa.it, alessio.balsini@...il.com,
bristot@...hat.com, will.deacon@....com,
andrea.parri@...rulasolutions.com, dietmar.eggemann@....com,
patrick.bellasi@....com, henrik@...tad.us,
linux-rt-users@...r.kernel.org
Subject: Re: [RFD/RFC PATCH 5/8] sched: Add proxy execution
On 11/10/18 14:53, Peter Zijlstra wrote:
[...]
> I think it was the safe and simple choice; note that we're not migrating
> just a single @p, but a whole chain of @p. rq->curr must not be any of the
> possible @p's. rq->idle, is per definition not one of the @p's.
>
> Does that make sense?
It does, and I guess is most probably the safest choice indeed. But,
just to put together a proper comment for next version..
The chain we are migrating is composed of blocked_task(s), so tasks that
blocked on a mutex owned by @p. Now, if such a chain has been built, it
means that proxy() has been called "for" @p previously, and @p might be
curr while one of its waiters might be proxy. So, none of the blocked_
task(s) should be rq->curr (even if one of their scheduling context
might be in use)?
Powered by blists - more mailing lists