From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932895AbdLRLZS (ORCPT ); Mon, 18 Dec 2017 06:25:18 -0500 Received: from outbound-smtp16.blacknight.com ([46.22.139.233]:38319 "EHLO outbound-smtp16.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757677AbdLRLZR (ORCPT ); Mon, 18 Dec 2017 06:25:17 -0500 Date: Mon, 18 Dec 2017 11:25:15 +0000 From: Mel Gorman To: Mike Galbraith Cc: Peter Zijlstra , Ingo Molnar , Matt Fleming , LKML Subject: Re: [PATCH 4/4] sched: Allow tasks to stack with a workqueue on the same CPU Message-ID: <20171218112515.b6f5i6fjwsmz2575@techsingularity.net> References: <20171218094327.19562-1-mgorman@techsingularity.net> <20171218094327.19562-5-mgorman@techsingularity.net> <1513593870.6876.27.camel@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1513593870.6876.27.camel@gmx.de> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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