Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1064978ybl; Wed, 8 Jan 2020 10:22:56 -0800 (PST) X-Google-Smtp-Source: APXvYqzfyN+crA43ieE/NQGCu7EbWwySFS24cVYJEt7OWEcYx3UL9512a8axgggHkR/YTk8ZNuPN X-Received: by 2002:aca:4a08:: with SMTP id x8mr4197850oia.39.1578507776781; Wed, 08 Jan 2020 10:22:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578507776; cv=none; d=google.com; s=arc-20160816; b=SgbQFok9hrxIjd2HiOzO3nXkHnrrtwbxHcdGqbDAYnjaPqE51HWz0bJo5gsj+LfLMw 7jIKbc4fcAsNs5PnwSvbeXyH3T80ORRhOHjy2Tli2hTWLIt9CHsxGPBS5kBtiRh7/dHi kLkCpMhDYwoLwnBPs0UP+HOGr89bnSHIm3uP677127F4r3VeL3gS5jTNns734Uot7QWQ 8vEzr5u2qvvaCZKj89sj6l/sJgsnOY9Es3SnU8NwfmMm+2BH78EUyUOijCKvNH95lMFi gOdjE3gkbXRHazvQb6g+NMX5j0psaODDFhL8y5z+OK40CWHitOl60X8ThuwqjytflPhb kOxg== 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=05tvhOyfoS0jHntm23vVvj1IGDvwj2+cn8zbRQ4aqn8=; b=yipoOPr31kQ2lhaN2Cs1H6bT65V9BLr4F+0mGbdi0OsgSc7RlodxcCROzmfvuVSwAR BuR1EOTPeDH268sAfNsAklzFgEgZr+ZVEODCMmVEfG9pbBqNsMzIUgQiOkZJV6QdlzAG 2POgwinDCgoDPTAOPmr7RdJgsR53+dUmZyGqf0MwyF+lWDYPIJ7q7H6fdRoReMD9mDry zy4pYFJYXG3jqLNhJlkzQ2W1CXYatgK923PZwiozwiXYwWTbYRaFxpyESPcYzfBzUjEW Rv8mlvVU4alA5HUSEk0aOXkWnNkz9w/rNmzSsjPXJbqDiOa/L3FjmoUIzRE63Y4E4lpk CV/Q== 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 w26si2024472otl.213.2020.01.08.10.22.44; Wed, 08 Jan 2020 10:22:56 -0800 (PST) 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 S1727635AbgAHPuE (ORCPT + 99 others); Wed, 8 Jan 2020 10:50:04 -0500 Received: from foss.arm.com ([217.140.110.172]:46370 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726186AbgAHPuD (ORCPT ); Wed, 8 Jan 2020 10:50:03 -0500 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 5806031B; Wed, 8 Jan 2020 07:50:03 -0800 (PST) Received: from [10.0.2.15] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 78B9D3F534; Wed, 8 Jan 2020 07:50:01 -0800 (PST) Subject: Re: [PATCH] sched, fair: Allow a small load imbalance between low utilisation SD_NUMA domains v3 To: Mel Gorman , Vincent Guittot Cc: Hillf Danton , Rik van Riel , Ingo Molnar , Peter Zijlstra , Phil Auld , Srikar Dronamraju , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Parth Shah , LKML References: <20200106144250.GA3466@techsingularity.net> <04033a63f11a9c59ebd2b099355915e4e889b772.camel@surriel.com> <20200106163303.GC3466@techsingularity.net> <20200107015111.4836-1-hdanton@sina.com> <20200107091256.GE3466@techsingularity.net> <20200107101646.GG3466@techsingularity.net> From: Valentin Schneider Message-ID: Date: Wed, 8 Jan 2020 15:49:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20200107101646.GG3466@techsingularity.net> Content-Type: text/plain; charset=iso-8859-15 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 07/01/2020 10:16, Mel Gorman wrote: > I think running tasks at least is the least bad metric. idle CPUs gets > caught up in corner cases with bindings and util_avg can be skewed by > outliers. Running tasks is a sensible starting point until there is a > concrete use case that shows it is unworkable. I'd tend to agree with you here. Also; this being in the group_has_spare imbalance type we have some guarantees that the group is not overutilized. If we keep some threshold of 'sum_nr_running < group_weight / 2', then this "naturally" puts a hard limit of 50% total group utilization (corner case where all tasks are 100% util). > Lets see what you think of > the other untested patch I posted that takes the group weight and child > domain weight into account. >