Messages in this thread | | | Date | Wed, 29 Jan 2020 18:38:52 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH] sched, fair: Allow a per-cpu kthread waking a task to stack on the same CPU |
| |
On Tue, Jan 28, 2020 at 09:10:12AM +0000, Mel Gorman wrote: > Peter, Ingo and Vincent -- I know the timing is bad due to the merge > window but do you have any thoughts on allowing select_idle_sibling to > stack a wakee task on the same CPU as a waker in this specific case?
I sort of see, but *groan*...
so if the kworker unlocks a contended mutex/rwsem/completion...
I suppose the fact that it limits it to tasks that were running on the same CPU limits the impact if we do get it wrong.
Elsewhere you write:
> I would prefer the wakeup code did not have to signal that it's a > synchronous wakeup. Sync wakeups so exist but callers got it wrong many > times where stacking was allowed and then the waker did not go to sleep. > While the chain of events are related, they are not related in a very > obvious way. I think it's much safer to keep this as a scheduler > heuristic instead of depending on callers to have sufficient knowledge > of the scheduler implementation.
That is true; the existing WF_SYNC has caused many issues for maybe being too strong.
But what if we create a new hint that combines both these ideas? Say WF_COMPLETE and subject that to these same criteria. This way we can eliminate wakeups from locks and such (they won't have this set).
Or am I just making things complicated again?
| |