Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp3603ybx; Wed, 30 Oct 2019 10:28:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqy1C+nledvvEnul2qpybwpqFgn2uW62NzTfJq882oexeXQTG78CuicJT0XDQRYgFEUtDgpL X-Received: by 2002:a05:6402:488:: with SMTP id k8mr862226edv.293.1572456520422; Wed, 30 Oct 2019 10:28:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572456520; cv=none; d=google.com; s=arc-20160816; b=SjqGvPKOm/EJj1IRm8vQ8ZpBwYsqniAWoTI+/iNb/hDzuY9vAsjDAEsOojGzAPI0a9 l8V0MNb3yFJRxKXPePJ1k2CnM9WRuXnG5K6ZKwZSjP+EzMr0/3mPOZZ1Lx57wrnGMJAW X4HBjIUKg4O+uZH8LdEFSnFVxtYQm6pw1mxgkI2P4O6zb84iCpl8CXo3M/QrxhqpOj5N +/pOildoVlRsMxsZ2BM/NkvGuvqvMPW7R6aS0m3sLesItLlV1/a88raslsXc0iTu8MRb m/Kh1nH6D1748BD18XY/n6vWkVs+1NDWpN/bME0Q0i/rdhYyH0SdiX4Pl1qs0VqMSJ0V UVkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Xzzxf4+4uL3R5eSgEyYJHUHG8/lhA/w8BaQAKhi6c0A=; b=bgt7tIIj5o6005Zxwpbv3c1Mk6Xg2E4IV5MB1FN1MCwLLNWveFNn2yAQAAs+pYUvM2 qAlCiNV+6RL1OHYAvI771t4xIMy4R4liSI+yAANEO0G5vf+YklklI2EADe0dWeZE640L qD+mG8Z6WUmIHOALHJu1JALXvWNF4cd47Cx6eKiWRetRXMWvwXq9t3DZPA4QYJFObzd+ PRZZMF8RGaRnfYuRxPdXBHWfEHS0nNTuTTTkC6pGCneXMFT2IfOxm0lPQA+LmWklPVoi LG9tJb2sAxofrfRY8or9EXXvjVPCLma2MbpdNUqDy8UKdkjqLx/VLa2bFTPBT6PlIPFn zBjw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x7si1639674ejw.75.2019.10.30.10.28.15; Wed, 30 Oct 2019 10:28:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727470AbfJ3RZQ (ORCPT + 99 others); Wed, 30 Oct 2019 13:25:16 -0400 Received: from foss.arm.com ([217.140.110.172]:38426 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726488AbfJ3RZP (ORCPT ); Wed, 30 Oct 2019 13:25:15 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 131F71FB; Wed, 30 Oct 2019 10:25:15 -0700 (PDT) Received: from [10.188.222.161] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 976653F6C4; Wed, 30 Oct 2019 10:25:11 -0700 (PDT) Subject: Re: [PATCH v4 00/10] sched/fair: rework the CFS load balance To: Phil Auld Cc: Dietmar Eggemann , Vincent Guittot , Ingo Molnar , Mel Gorman , linux-kernel , Ingo Molnar , Peter Zijlstra , Srikar Dronamraju , Quentin Perret , Morten Rasmussen , Hillf Danton , Parth Shah , Rik van Riel References: <20191021075038.GA27361@gmail.com> <20191024123844.GB2708@pauld.bos.csb> <20191024134650.GD2708@pauld.bos.csb> <20191025133325.GA2421@pauld.bos.csb> <20191030143937.GC1686@pauld.bos.csb> <564ca629-5c34-dbd1-8e64-2da6910b18a3@arm.com> <20191030171914.GF1686@pauld.bos.csb> From: Valentin Schneider Message-ID: <4c52d81f-4b3b-d7e8-c124-b90b4584a6d3@arm.com> Date: Wed, 30 Oct 2019 18:25:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191030171914.GF1686@pauld.bos.csb> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/10/2019 18:19, Phil Auld wrote: >> Well from the code nobody but us (asymmetric capacity systems) set >> SD_BALANCE_WAKE. I was however curious if there were some folks who set it >> with out of tree code for some reason. >> >> As Dietmar said, not having SD_BALANCE_WAKE means you'll never go through >> the slow path on wakeups, because there is no domain with SD_BALANCE_WAKE for >> the domain loop to find. Depending on your topology you most likely will >> go through it on fork or exec though. >> >> IOW wake_wide() is not really widening the wakeup scan on wakeups using >> mainline topology code (disregarding asymmetric capacity systems), which >> sounds a bit... off. > > Thanks. It's not currently set. I'll set it and re-run to see if it makes > a difference. > Note that it might do more harm than good, it's not set in the default topology because it's too aggressive, see 182a85f8a119 ("sched: Disable wakeup balancing") > > However, I'm not sure why it would be making a difference for only the cgroup > case. If this is causing issues I'd expect it to effect both runs. > > In general I think these threads want to wake up the last cpu they were on. > And given there are fewer cpu bound tasks that CPUs that wake cpu should, > more often than not, be idle. > > > Cheers, > Phil > > >