linux-kernel - Re: [PATCH 4/4] sched: Allow tasks to stack with a workqueue 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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 18 Dec 2017 11:25:15 +0000
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Mike Galbraith <efault@....de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] sched: Allow tasks to stack with a workqueue on the
 same CPU

On Mon, Dec 18, 2017 at 11:44:30AM +0100, Mike Galbraith wrote:
> On Mon, 2017-12-18 at 09:43 +0000, Mel Gorman wrote:
> > If tasks wake a kworker to do some work and is woken on completion and it
> > was a per-cpu kworker that was used then a situation can arise where the
> > current CPU is always active when the kworker is waking and select_idle_sibling
> > moves the task. This leads to a situation where a task moves around the socket
> > each time a kworker is used even through the relationship is effectively sync.
> > This patch special cases a kworker running on the same CPU. It has a noticable
> > impact on migrations and performance of dbench running with the XFS filesystem
> > but has no impact on ext4 as ext4 interacts with a kthread, not a kworker.
> 
> I think intentional stacking is a very bad idea unless you know with
> absolute certainty that waker/wakee are in fact 100% synchronous.  This
> is IMO the wrong way to go about combating the excessive bouncing, that
> can be achieved by simple ratelimiting.
> 

Grand, I thought the patch was a bit optimistic but was surprised at the
level of impact for a workload that really did have a synchronous
relationship between waker and wakee. Might be worth revisiting it in
the future, be it rate-limiting or some other mechanism.

Thanks.

-- 
Mel Gorman
SUSE Labs