Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp3800287imd; Mon, 29 Oct 2018 12:34:22 -0700 (PDT) X-Google-Smtp-Source: AJdET5fdtu6DSoG5mZW9/nmngmCQRSmXMktjG7l2BttFRfSuUI6pIuToVR20eVsOknqNrlwIDTJP X-Received: by 2002:a63:ec11:: with SMTP id j17-v6mr14843830pgh.388.1540841662814; Mon, 29 Oct 2018 12:34:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540841662; cv=none; d=google.com; s=arc-20160816; b=GqR/ETQO37fWZppDirxa8YJ+u0YW5C9/HI0QvGiNGgVaJyPVCgqaGJD3GLRjS1GlMA 6tzz/pSOAnnzP5ZJiSc++rRWZK8yY84GBHPpeCPVWqqFb1DVIaY+RwtGvqdo03XWq0NN Vm27AHL5eioTWrhzAB9I/lwyW45+0sun3i68Ti3jco+0oIphTXTtrBTSbx95frot7023 iSqqrHdcFTQOLWdTJ4NG0LfS15VuNsDtLOvCT/Cz2PFTpmcOcNjCUFVVxF/u5KYm6qlo +NPDNPWhJA+viIzzfaXJ51IEP4trT+fIJmk2nan7jkvnD4FhMAUVKGpX8/1xhhfoy2gX m0fQ== 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:dkim-signature; bh=ohrRml1DVL3QOAHeC2fJX5vmlo5wnZeHUHLRlPhYEWU=; b=L+RFRItB/Z3OuurpFcLmNZEviLycoc8Z7TbyIWnD94EjWnTaggYUEzDOby0BHAK6Jr ywWie4InYeYYLyeSfVHuZppjgImwNWrE8P3UyUsqYrsrUkXpy8qdnZ+XX4gKcGAcMQr2 1cN0AVcbaje+6la7P1/hVWNDnFIpM3L4VNZY6hWUH+Q/ryWffBPjLC518S7I1x5zD0cx JKndN98MtQTR29FU7cRPhY5aYrZK7lh3mKcewyfIed5C07qH8NfbwYN96HGT6uWMU3so W4OVu/+TFYl9SSYwSyRKNA2/w2/tNjIcCjcGy4ufbwcv4udS8Ggt/hHNZtdSHMgfko85 /+ZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=GmcTJva4; 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 o13-v6si20961519pgh.61.2018.10.29.12.34.06; Mon, 29 Oct 2018 12:34:22 -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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=GmcTJva4; 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 S1727816AbeJ3EXt (ORCPT + 99 others); Tue, 30 Oct 2018 00:23:49 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:46466 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725781AbeJ3EXt (ORCPT ); Tue, 30 Oct 2018 00:23:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To: Subject:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ohrRml1DVL3QOAHeC2fJX5vmlo5wnZeHUHLRlPhYEWU=; b=GmcTJva4PiKwfCDklaq2/tmhH CfV9owyT0dM609geEf1398SWvHnocZO0k1SuLkOBHCt53JEl+5DOe5w5oqBu3VPEqPw3uVEPqKgfR Vdn2jYzI0Dy+qOrtwdPo73fB0FupZoTTAiMpiYEn9lQB5TtpxOuZLR0lqPRuL3C4xWmzfM6sOLMVl RnfFNaYwQkTrihD37W35aq/SoTs+NBkm5ClKsAbZ5ssM+4jL395FvlRrffqj1UktGoqNqFkRpUxvZ nabZGlbLtxZod2nA7CKVe/as6ZeXu7yuh+2AF2MiIL58vjGiro4WI/acYk5PLV+gxULbj3rDcKd7x ZmgyArD4w==; Received: from static-50-53-52-16.bvtn.or.frontiernet.net ([50.53.52.16] helo=midway.dunlab) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1gHDID-00076I-4e; Mon, 29 Oct 2018 19:33:41 +0000 Subject: Re: [PATCH v5 01/15] sched/core: uclamp: extend sched_setattr to support utilization clamping To: Patrick Bellasi , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Vincent Guittot , Viresh Kumar , Paul Turner , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan , linux-api@vger.kernel.org References: <20181029183311.29175-1-patrick.bellasi@arm.com> <20181029183311.29175-2-patrick.bellasi@arm.com> From: Randy Dunlap Message-ID: <5d17113b-d0c8-dafe-f4f9-527722749bb8@infradead.org> Date: Mon, 29 Oct 2018 12:33:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181029183311.29175-2-patrick.bellasi@arm.com> Content-Type: text/plain; charset=utf-8 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 10/29/18 11:32 AM, Patrick Bellasi wrote: > diff --git a/include/uapi/linux/sched/types.h b/include/uapi/linux/sched/types.h > index 10fbb8031930..fde7301ed28c 100644 > --- a/include/uapi/linux/sched/types.h > +++ b/include/uapi/linux/sched/types.h > @@ -53,6 +73,30 @@ struct sched_param { > * As of now, the SCHED_DEADLINE policy (sched_dl scheduling class) is the > * only user of this new interface. More information about the algorithm > * available in the scheduling class file or in Documentation/. > + * > + * Task Utilization Attributes > + * =========================== > + * > + * A subset of sched_attr attributes allows to specify the utilization which > + * should be expected by a task. These attributes allow to inform the > + * scheduler about the utilization boundaries within which it is expected to > + * schedule the task. These boundaries are valuable hints to support scheduler > + * decisions on both task placement and frequencies selection. > + * > + * @sched_util_min represents the minimum utilization > + * @sched_util_max represents the maximum utilization > + * > + * Utilization is a value in the range [0..SCHED_CAPACITY_SCALE] which > + * represents the percentage of CPU time used by a task when running at the > + * maximum frequency on the highest capacity CPU of the system. Thus, for > + * example, a 20% utilization task is a task running for 2ms every 10ms. > + * > + * A task with a min utilization value bigger then 0 is more likely to be than > + * scheduled on a CPU which has a capacity big enough to fit the specified > + * minimum utilization value. > + * A task with a max utilization value smaller then 1024 is more likely to be > + * scheduled on a CPU which do not necessarily have more capacity then the does than > + * specified max utilization value. > */ > struct sched_attr { > __u32 size; cheers. -- ~Randy