Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp977993ybe; Wed, 4 Sep 2019 10:33:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqzGI0xblFlZ1v8rzcZbvDPuLjpgnXttPsxer9rwQRMu12/K3ICY9xCY6y4TG7Y9BJae8dWT X-Received: by 2002:a17:90a:30e8:: with SMTP id h95mr6306957pjb.44.1567618420598; Wed, 04 Sep 2019 10:33:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567618420; cv=none; d=google.com; s=arc-20160816; b=SS9cNcNg8Ka5igE7L9hZZMnM2wk/qKSHAMAHPgf3WwQWtbe0qrzY5H75hIWLyoQBnz usGsSO7WjoLtHNkZ5zFImbeNtkF8LdzlEx36EKRFD1TrN8vOzCZZDfipux9rB6yVA8fU S+q7bIE13JGDDcWIcCBOlh+YV0xveSx5+fb8dENnL4JiSNVXkEklyshEMLh7DljbxRmS vHioBpJy/+0mkWpzSDbNMhifgmdYPn7wQcUDO+Aoig0/tfZGZlaeo5hR87o4uNL79Voj ZDfCjxCQfdUhDhMM6zGbyR7LN4NVURs3HJEC4c9h2VNEuCBGiBS5CDytbWNrmZbirHp4 M5TA== 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:openpgp:from:references:cc:to; bh=v2nIyPtue+X82NMn4AGuCmcov/+fLZCYi4fEs7KrYag=; b=uu2tkpkM4BXRNzMgeewr4dLmPz5CpdPPOzQfbwh98bqcI0vb7YgV39bw4sW6XHov1M Oin9Wkcyqktfpc3KS1KX3seTMEOH2HlroiNxrCIZ7oG6zrOa5sxnoB2PnvdzdkhYFFPs jjdHELT8RAzzT7Tdo3o0JfPyJx2W5Dhsec+RLF9EAuh75ilhry1N8HSuG7Mja+cYKKOK Tkw8WdwKWuu7CuE+WKjR+W/UW+LmJ2LY2IWcCPalf9l0qDhchfUOBtuhtgSd5CP4JGOR hQdHpt6xaCRiB4tNmLgUOSQgQlSZriMhzmkhBNy4+aiccsoSe4yGvgdgUUDz4ZnZT71B tDhA== 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 x10si4596341pln.268.2019.09.04.10.33.24; Wed, 04 Sep 2019 10:33: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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732125AbfIDRcH (ORCPT + 99 others); Wed, 4 Sep 2019 13:32:07 -0400 Received: from mga07.intel.com ([134.134.136.100]:26699 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729594AbfIDRcH (ORCPT ); Wed, 4 Sep 2019 13:32:07 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2019 10:32:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,467,1559545200"; d="scan'208";a="199078286" Received: from schen9-desk.jf.intel.com (HELO [10.54.74.162]) ([10.54.74.162]) by fmsmga001.fm.intel.com with ESMTP; 04 Sep 2019 10:32:05 -0700 To: subhra mazumdar , linux-kernel@vger.kernel.org Cc: peterz@infradead.org, mingo@redhat.com, tglx@linutronix.de, steven.sistare@oracle.com, dhaval.giani@oracle.com, daniel.lezcano@linaro.org, vincent.guittot@linaro.org, viresh.kumar@linaro.org, mgorman@techsingularity.net, parth@linux.ibm.com, patrick.bellasi@arm.com References: <20190830174944.21741-1-subhra.mazumdar@oracle.com> <20190830174944.21741-2-subhra.mazumdar@oracle.com> From: Tim Chen Openpgp: preference=signencrypt 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 1/9] sched,cgroup: Add interface for latency-nice Message-ID: <11aaa3a8-e6b9-cf1f-08bb-0f8e1b63942b@linux.intel.com> Date: Wed, 4 Sep 2019 10:32:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190830174944.21741-2-subhra.mazumdar@oracle.com> 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 8/30/19 10:49 AM, subhra mazumdar wrote: > Add Cgroup interface for latency-nice. Each CPU Cgroup adds a new file > "latency-nice" which is shared by all the threads in that Cgroup. Subhra, Thanks for posting the patchset. Having a latency nice hint is useful beyond idle load balancing. I can think of other application scenarios, like scheduling batch machine learning AVX 512 processes with latency sensitive processes. AVX512 limits the frequency of the CPU and it is best to avoid latency sensitive task on the same core with AVX512. So latency nice hint allows the scheduler to have a criteria to determine the latency sensitivity of a task and arrange latency sensitive tasks away from AVX512 tasks. You configure the latency hint on a cgroup basis. But I think not all tasks in a cgroup necessarily have the same latency sensitivity. For example, I can see that cgroup can be applied on a per user basis, and the user could run different tasks that have different latency sensitivity. We may also need a way to configure latency sensitivity on a per task basis instead on a per cgroup basis. Tim > @@ -631,6 +631,7 @@ struct task_struct { > int static_prio; > int normal_prio; > unsigned int rt_priority; > + u64 latency_nice; Does it need to be 64 bit? Max latency nice is only 100. > > const struct sched_class *sched_class; > struct sched_entity se; > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 874c427..47969bc 100644 > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h > index b52ed1a..365c928 100644 > --- a/kernel/sched/sched.h > +++ b/kernel/sched/sched.h > @@ -143,6 +143,13 @@ static inline void cpu_load_update_active(struct rq *this_rq) { } > #define NICE_0_LOAD (1L << NICE_0_LOAD_SHIFT) > > /* > + * Latency-nice default value > + */ Will be useful to add comments to let reader know that higher latency nice number means a task is more latency tolerant. Is there a reason for setting the default to be a low value of 5? Seems like we will default to only to search the same core for idle cpu on a smaller system, as we only search 5% of the cpu span of the target sched domain. > +#define LATENCY_NICE_DEFAULT 5 > +#define LATENCY_NICE_MIN 1 > +#define LATENCY_NICE_MAX 100 > +