linux-kernel - Re: [PATCH] sched, fair: Allow a per-cpu kthread waking a task to stack on the same CPU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200129173852.GP14914@hirez.programming.kicks-ass.net>
Date:   Wed, 29 Jan 2020 18:38:52 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Mel Gorman <mgorman@...hsingularity.net>
Cc:     Dave Chinner <david@...morbit.com>, Ingo Molnar <mingo@...hat.com>,
        Tejun Heo <tj@...nel.org>, Phil Auld <pauld@...hat.com>,
        Ming Lei <ming.lei@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-fsdevel@...r.kernel.org, linux-xfs@...r.kernel.org,
        linux-kernel@...r.kernel.org
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?