sched: Prepare for Core-wide rq->lock
authorPeter Zijlstra <peterz@infradead.org>
Tue, 2 Mar 2021 11:16:48 +0000 (12:16 +0100)
committerPeter Zijlstra <peterz@infradead.org>
Wed, 12 May 2021 09:43:26 +0000 (11:43 +0200)
commitd66f1b06b5b438cd20ba3664b8eef1f9c79e84bf
treef5f0faf4e54e9d9f3ded4f26b007a7fa544173ab
parent5cb9eaa3d274f75539077a28cf01e3563195fa53
sched: Prepare for Core-wide rq->lock

When switching on core-sched, CPUs need to agree which lock to use for
their RQ.

The new rule will be that rq->core_enabled will be toggled while
holding all rq->__locks that belong to a core. This means we need to
double check the rq->core_enabled value after each lock acquire and
retry if it changed.

This also has implications for those sites that take multiple RQ
locks, they need to be careful that the second lock doesn't end up
being the first lock.

Verify the lock pointer after acquiring the first lock, because if
they're on the same core, holding any of the rq->__lock instances will
pin the core state.

While there, change the rq->__lock order to CPU number, instead of rq
address, this greatly simplifies the next patch.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Don Hiatt <dhiatt@digitalocean.com>
Tested-by: Hongyu Ning <hongyu.ning@linux.intel.com>
Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
Link: https://lkml.kernel.org/r/YJUNY0dmrJMD/BIm@hirez.programming.kicks-ass.net
kernel/sched/core.c
kernel/sched/sched.h