Re: [PATCH 4/4] sched: Allow tasks to stack with a workqueue on the same CPU

[Mel Gorman <mgorman@techsingularity.net>]

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