Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp7261514ybf; Fri, 6 Mar 2020 13:45:10 -0800 (PST) X-Google-Smtp-Source: ADFU+vsWddYxmqRYK66tfh+wgrVAscUgYnx+ORCx2Bz06YILj73U95wd3+fPlmVJh+7AW8Xe5SZP X-Received: by 2002:a9d:20c1:: with SMTP id x59mr4464348ota.286.1583531109992; Fri, 06 Mar 2020 13:45:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583531109; cv=none; d=google.com; s=arc-20160816; b=XEeeMEn+B+uobJX4Mg+VEyXykytnnZQpYNU/W9D6884rIWn1G/0hKY89hQowrINb/Y cK7TyaXyep4MGR/d7fT65yA0q/wCsA2an2iwMrl55fd7JcmUmGouA4POYTq5D1GvAQpU EV1SCzlTouVBgn2jXs/F/Xaks17H4+gNOgazCiEZl9ULnpGFKjFdr+hK6pPQcEZ66/lB WU9iTdaLGmb+wCMnDYfeasCQ8LfadSrGZjB0I7InKARcVBJLX+erHx4R7L1k6X93W3bc 0Ox6Fi/drzwNDa7GTSxDSdgaZBkGr84HAiT1ZrlLcb+EOhEUTOde38wkydLVb4w7SugR /laA== 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:subject:autocrypt:from:references:cc:to; bh=TV88f1ViQob/uI0qV0h23Ks4sKk2l/yvwBEgNrEInuQ=; b=cvyabXpNWUV4jwnOvPc/luCkdgfLVutFp+CP/vHCbNd7o2NYwyPZSP9P/HAYMHNYC0 WC4C+1g4mXRr1axU7YZ/VmLd2bKwDnrcS8apG+/sPVpPvFMX6XBYVgZiG63Isi2Xi1oQ 1fIlu+yCHi3fO0Jgl4rKAZkXnDAdge3n22AL4ofcdY0oc/Z9tT+AVlpjV5jc2DvVpQpa OG5ddvajwM9V/Gah9yCXLGx5uPEjkUsBXECP76EQCR6FnZ4OWXRUBnBKRMgGHeI9geWk e+H8ft2XxmWi7vt+bWptxXZJnR+c5YNlZdBP28SosN6IzoYXrAjALVa8AvH8VbEI862f uk/w== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p83si354590oih.198.2020.03.06.13.44.57; Fri, 06 Mar 2020 13:45:09 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726378AbgCFVoL (ORCPT + 99 others); Fri, 6 Mar 2020 16:44:11 -0500 Received: from mga18.intel.com ([134.134.136.126]:35287 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726245AbgCFVoL (ORCPT ); Fri, 6 Mar 2020 16:44:11 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2020 13:44:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,523,1574150400"; d="scan'208";a="275701723" Received: from schen9-desk.jf.intel.com (HELO [10.54.74.162]) ([10.54.74.162]) by fmsmga002.fm.intel.com with ESMTP; 06 Mar 2020 13:44:09 -0800 To: Phil Auld Cc: Aaron Lu , Aubrey Li , Vineeth Remanan Pillai , Julien Desfossez , Nishanth Aravamudan , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Paul Turner , Linus Torvalds , Linux List Kernel Mailing , Dario Faggioli , =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , Kees Cook , Greg Kerr , Valentin Schneider , Mel Gorman , Pawan Gupta , Paolo Bonzini References: <29d43466-1e18-6b42-d4d0-20ccde20ff07@linux.intel.com> <20200225034438.GA617271@ziqianlu-desktop.localdomain> <20200227020432.GA628749@ziqianlu-desktop.localdomain> <20200227141032.GA30178@pauld.bos.csb> <20200228025405.GA634650@ziqianlu-desktop.localdomain> <20200306024116.GA16400@ziqianlu-desktop.localdomain> <98719a4e-f620-dc8c-f29f-fd63c43e1597@linux.intel.com> <20200306183340.GC23145@pauld.bos.csb> From: Tim Chen Autocrypt: addr=tim.c.chen@linux.intel.com; prefer-encrypt=mutual; keydata= mQINBE6ONugBEAC1c8laQ2QrezbYFetwrzD0v8rOqanj5X1jkySQr3hm/rqVcDJudcfdSMv0 BNCCjt2dofFxVfRL0G8eQR4qoSgzDGDzoFva3NjTJ/34TlK9MMouLY7X5x3sXdZtrV4zhKGv 3Rt2osfARdH3QDoTUHujhQxlcPk7cwjTXe4o3aHIFbcIBUmxhqPaz3AMfdCqbhd7uWe9MAZX 7M9vk6PboyO4PgZRAs5lWRoD4ZfROtSViX49KEkO7BDClacVsODITpiaWtZVDxkYUX/D9OxG AkxmqrCxZxxZHDQos1SnS08aKD0QITm/LWQtwx1y0P4GGMXRlIAQE4rK69BDvzSaLB45ppOw AO7kw8aR3eu/sW8p016dx34bUFFTwbILJFvazpvRImdjmZGcTcvRd8QgmhNV5INyGwtfA8sn L4V13aZNZA9eWd+iuB8qZfoFiyAeHNWzLX/Moi8hB7LxFuEGnvbxYByRS83jsxjH2Bd49bTi XOsAY/YyGj6gl8KkjSbKOkj0IRy28nLisFdGBvgeQrvaLaA06VexptmrLjp1Qtyesw6zIJeP oHUImJltjPjFvyfkuIPfVIB87kukpB78bhSRA5mC365LsLRl+nrX7SauEo8b7MX0qbW9pg0f wsiyCCK0ioTTm4IWL2wiDB7PeiJSsViBORNKoxA093B42BWFJQARAQABtDRUaW0gQ2hlbiAo d29yayByZWxhdGVkKSA8dGltLmMuY2hlbkBsaW51eC5pbnRlbC5jb20+iQI+BBMBAgAoAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCXFIuxAUJEYZe0wAKCRCiZ7WKota4STH3EACW 1jBRzdzEd5QeTQWrTtB0Dxs5cC8/P7gEYlYQCr3Dod8fG7UcPbY7wlZXc3vr7+A47/bSTVc0 DhUAUwJT+VBMIpKdYUbvfjmgicL9mOYW73/PHTO38BsMyoeOtuZlyoUl3yoxWmIqD4S1xV04 q5qKyTakghFa+1ZlGTAIqjIzixY0E6309spVTHoImJTkXNdDQSF0AxjW0YNejt52rkGXXSoi IgYLRb3mLJE/k1KziYtXbkgQRYssty3n731prN5XrupcS4AiZIQl6+uG7nN2DGn9ozy2dgTi smPAOFH7PKJwj8UU8HUYtX24mQA6LKRNmOgB290PvrIy89FsBot/xKT2kpSlk20Ftmke7KCa 65br/ExDzfaBKLynztcF8o72DXuJ4nS2IxfT/Zmkekvvx/s9R4kyPyebJ5IA/CH2Ez6kXIP+ q0QVS25WF21vOtK52buUgt4SeRbqSpTZc8bpBBpWQcmeJqleo19WzITojpt0JvdVNC/1H7mF 4l7og76MYSTCqIKcLzvKFeJSie50PM3IOPp4U2czSrmZURlTO0o1TRAa7Z5v/j8KxtSJKTgD lYKhR0MTIaNw3z5LPWCCYCmYfcwCsIa2vd3aZr3/Ao31ZnBuF4K2LCkZR7RQgLu+y5Tr8P7c e82t/AhTZrzQowzP0Vl6NQo8N6C2fcwjSrkCDQROjjboARAAx+LxKhznLH0RFvuBEGTcntrC 3S0tpYmVsuWbdWr2ZL9VqZmXh6UWb0K7w7OpPNW1FiaWtVLnG1nuMmBJhE5jpYsi+yU8sbMA 5BEiQn2hUo0k5eww5/oiyNI9H7vql9h628JhYd9T1CcDMghTNOKfCPNGzQ8Js33cFnszqL4I N9jh+qdg5FnMHs/+oBNtlvNjD1dQdM6gm8WLhFttXNPn7nRUPuLQxTqbuoPgoTmxUxR3/M5A KDjntKEdYZziBYfQJkvfLJdnRZnuHvXhO2EU1/7bAhdz7nULZktw9j1Sp9zRYfKRnQdIvXXa jHkOn3N41n0zjoKV1J1KpAH3UcVfOmnTj+u6iVMW5dkxLo07CddJDaayXtCBSmmd90OG0Odx cq9VaIu/DOQJ8OZU3JORiuuq40jlFsF1fy7nZSvQFsJlSmHkb+cDMZDc1yk0ko65girmNjMF hsAdVYfVsqS1TJrnengBgbPgesYO5eY0Tm3+0pa07EkONsxnzyWJDn4fh/eA6IEUo2JrOrex O6cRBNv9dwrUfJbMgzFeKdoyq/Zwe9QmdStkFpoh9036iWsj6Nt58NhXP8WDHOfBg9o86z9O VMZMC2Q0r6pGm7L0yHmPiixrxWdW0dGKvTHu/DH/ORUrjBYYeMsCc4jWoUt4Xq49LX98KDGN dhkZDGwKnAUAEQEAAYkCJQQYAQIADwIbDAUCXFIulQUJEYZenwAKCRCiZ7WKota4SYqUEACj P/GMnWbaG6s4TPM5Dg6lkiSjFLWWJi74m34I19vaX2CAJDxPXoTU6ya8KwNgXU4yhVq7TMId keQGTIw/fnCv3RLNRcTAapLarxwDPRzzq2snkZKIeNh+WcwilFjTpTRASRMRy9ehKYMq6Zh7 PXXULzxblhF60dsvi7CuRsyiYprJg0h2iZVJbCIjhumCrsLnZ531SbZpnWz6OJM9Y16+HILp iZ77miSE87+xNa5Ye1W1ASRNnTd9ftWoTgLezi0/MeZVQ4Qz2Shk0MIOu56UxBb0asIaOgRj B5RGfDpbHfjy3Ja5WBDWgUQGgLd2b5B6MVruiFjpYK5WwDGPsj0nAOoENByJ+Oa6vvP2Olkl gQzSV2zm9vjgWeWx9H+X0eq40U+ounxTLJYNoJLK3jSkguwdXOfL2/Bvj2IyU35EOC5sgO6h VRt3kA/JPvZK+6MDxXmm6R8OyohR8uM/9NCb9aDw/DnLEWcFPHfzzFFn0idp7zD5SNgAXHzV PFY6UGIm86OuPZuSG31R0AU5zvcmWCeIvhxl5ZNfmZtv5h8TgmfGAgF4PSD0x/Bq4qobcfaL ugWG5FwiybPzu2H9ZLGoaRwRmCnzblJG0pRzNaC/F+0hNf63F1iSXzIlncHZ3By15bnt5QDk l50q2K/r651xphs7CGEdKi1nU0YJVbQxJQ== Subject: Re: [RFC PATCH v4 00/19] Core scheduling v4 Message-ID: <9bf44d68-de78-66d5-ea8c-6cc8a30d90c0@linux.intel.com> Date: Fri, 6 Mar 2020 13:44:08 -0800 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: <20200306183340.GC23145@pauld.bos.csb> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/6/20 10:33 AM, Phil Auld wrote: > On Fri, Mar 06, 2020 at 10:06:16AM -0800 Tim Chen wrote: >> On 3/5/20 6:41 PM, Aaron Lu wrote: >> >>>>> So this appeared to me like a question of: is it desirable to protect/enhance >>>>> high weight task performance in the presence of core scheduling? >>>> >>>> This sounds to me a policy VS mechanism question. Do you have any idea >>>> how to spread high weight task among the cores with coresched enabled? >>> >>> Yes I would like to get us on the same page of the expected behaviour >>> before jumping to the implementation details. As for how to achieve >>> that: I'm thinking about to make core wide load balanced and then high >>> weight task shall spread on different cores. This isn't just about load >>> balance, the initial task placement will also need to be considered of >>> course if the high weight task only runs a small period. >>> >> >> I am wondering why this is not happening: >> >> When the low weight task group has exceeded its cfs allocation during a cfs period, the task group >> should be throttled. In that case, the CPU cores that the low >> weight task group occupies will become idle, and allow load balance from the >> overloaded CPUs for the high weight task group to migrate over. >> > > cpu.shares is not quota. I think it will only get throttled if it has and > exceeds quota. Shares are supposed to be used to help weight contention > without providing a hard limit. > Ah yes. cpu.quota is not set in Aaron's test case. That said, I wonder if the time consumed is getting out of whack with the cpu shares assigned, we can leverage the quota mechanism to throttle those cgroup that have overused their shares of cpu. Most of the stats and machinery needed are already in the throttling mechanism. I am hoping that allowing task migration with task group mismatch under large load imbalance between CPUs will be good enough. Tim Tim