(Was: [RFC][PATCH] sched: Start stopper early)
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest3 patches 8 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | stop_machine: ensure that a queued callback will be called before cpu_stop_park()include/ kernel/ kernel/ | +15 | 5 replies | |
| 2/3 | stop_machine: introduce __cpu_stop_queue_work() and cpu_stop_queue_two_works()kernel/ | +26 | 0 replies | |
| 3/3 | stop_machine: change cpu_stop_queue_two_works() to rely on stopper->enabledkernel/ | +20 | 6 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/3] (Was: [RFC][PATCH] sched: Start stopper early)
Quoted 8 lines · Peter Zijlstra
So Heiko reported some 'interesting' fail where
stop_two_cpus()got stuck inmulti_cpu_stop()with one cpu waiting for another that never happens.It _looks_ like the 'other' cpu isn't running and the current best theory is that we race on cpu-up and get the
stop_two_cpus()call in before the stopper task is running.
How about this series? Slightly tested.
Note:
- To me this also looks like a preparation for lg lock removal, no matter how exactly we will do this.
- We can do more cleanups on top of this. Say remove preempt_disable
in stop_two_cpus().
Oleg.
include/linux/stop_machine.h | 1 kernel/cpu.c | 2 - kernel/stop_machine.c | 83 +++++++++++++++++++++++++++++-------------- 3 files changed, 58 insertions(+), 28 deletions(-)