Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3836573imm; Tue, 17 Jul 2018 11:05:34 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfKkjZ0NzHIfAEG0nDj11wX7pN9zOqCltixcdhW6amb0m5amnCzpNgjF+M+kqWx+hi89W/O X-Received: by 2002:aa7:8713:: with SMTP id b19-v6mr1692918pfo.151.1531850734219; Tue, 17 Jul 2018 11:05:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531850734; cv=none; d=google.com; s=arc-20160816; b=eoBYHVDKiEGGl8U05dMb90W0u1QdKPmNOHG9xK9rQsWKdL+muhZ40qFl2GgfjNYzuy eTeJ7MEiPNBAkBnYgabr8tDW8Q/72Mdjl4cpN0T05PVvhQ3Wl1Fu97C+M+1xTuIK0vN8 8bYNPkn3j2aYSOI7sf7f9xsITEcKOVt5jCTVKz0Q18wzfnfqGOwnao1AP+UgLf7ccpfb rgpU1r1Dz9Q0dJ2wPT2ZO1GH30fiLxzBhqlceicAMaxeXdR7afy/COexz9iao77qdqZ4 CM3TjBqi2ILGKrs6+s/wLsrBBkSmXo0+AzIjMaJZgaNjPOSD03JLk2QSqVC0QVAQLXLn vT9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=2kjvYhcfHU5ri5jurY3UTz/7geCp52c47PKwrE9wDB4=; b=aRw77wbNAtLosX/y/z6AoZe5KjHjczeaYEJyjlPKhCem3Q3wmRD7hX6lhG+M2Oihyb Bz3C3u/UzXA966sZXSrLfkE9CmH3PzDfXXh0wyBp4sq97Yh5l3Ea2i0DT6IXdKooNC+3 3AS49SlWDanTnEvTAT1tjc6RHX060wsrKKeAALZotexvS7p9idoOGOdMHd9MK6DeDoit WzbWqIoLFvSux4IJbi29I2zOMz5BbH9uv8leWkzRFGGVOyZ6MmK/yKZeNzLoGdvo9/bP 90fsZl5zaG1dCWk5qlbmeVt/XT1DLwuM93kdnAd5tVIXI0BVnRuA+zTxMWPWithH71Tt 0AEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b="bdq+/tKu"; 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 i64-v6si1377447pli.431.2018.07.17.11.05.19; Tue, 17 Jul 2018 11:05:34 -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=pass header.i=@joelfernandes.org header.s=google header.b="bdq+/tKu"; 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 S1729989AbeGQSiX (ORCPT + 99 others); Tue, 17 Jul 2018 14:38:23 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:41500 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729648AbeGQSiX (ORCPT ); Tue, 17 Jul 2018 14:38:23 -0400 Received: by mail-pg1-f193.google.com with SMTP id z8-v6so774017pgu.8 for ; Tue, 17 Jul 2018 11:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2kjvYhcfHU5ri5jurY3UTz/7geCp52c47PKwrE9wDB4=; b=bdq+/tKuSzrMKzEBFLfzLq0HTIviHCcam5W4mUEbCvj2I7VW4Vit0DivJtfZtekTGL l1TUiVOUVEvAqYQZ2uWveadlfi3q1Iimvp5FXn6OmA6+OvvP50/Gy8fdM4vGfzINwE7K itMgBVpEEiS4npnXfE5tAfvhIzod4oHA+hSzM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=2kjvYhcfHU5ri5jurY3UTz/7geCp52c47PKwrE9wDB4=; b=jPUAOaDr6hc94UMFaHad34BNNf0akRrGGq00cJodQpXI4FD9mIzX9Z9SuPbk66zmr4 F5uR+Btt7mFUTtnqETdLyKFtYk2keWTkBOOs4Wosy/UZJ8rj+Zfa4r3vRuZyQx3DrdaZ GFp1egqGanuJu1wlZK27uCyyY1HObEzCGX0yLKUE8a09xXZMkO8eBffViwNeXsydDfMq cmpK+s2CbQ3VSNb9ChOXZ0wJfMDNbLuEzL5VKRdr8SMPAbSVAOiT+4a64I5NwSDHdiqN Y+cBS08aotJktt4krPcAssmOQK/XviQDZ+CaXdNTbQ7gbwy6piBcFUe9W1uI78HpdPWA SjjA== X-Gm-Message-State: AOUpUlH/BoTdlc5i0BmrSicn6U8CSvRdjbYnkUWovmI0sFt/qA+azYn/ x/QZSf7h53Q6/l1BIqy8w8xOBg== X-Received: by 2002:a65:660a:: with SMTP id w10-v6mr2526209pgv.366.1531850675760; Tue, 17 Jul 2018 11:04:35 -0700 (PDT) Received: from localhost ([2620:0:1000:1600:3122:ea9c:d178:eb]) by smtp.gmail.com with ESMTPSA id 64-v6sm2935213pfi.89.2018.07.17.11.04.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 17 Jul 2018 11:04:35 -0700 (PDT) Date: Tue, 17 Jul 2018 11:04:34 -0700 From: Joel Fernandes To: Patrick Bellasi Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: Re: [PATCH v2 01/12] sched/core: uclamp: extend sched_setattr to support utilization clamping Message-ID: <20180717180434.GB150378@joelaf.mtv.corp.google.com> References: <20180716082906.6061-1-patrick.bellasi@arm.com> <20180716082906.6061-2-patrick.bellasi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180716082906.6061-2-patrick.bellasi@arm.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 16, 2018 at 09:28:55AM +0100, Patrick Bellasi wrote: > The SCHED_DEADLINE scheduling class provides an advanced and formal > model to define tasks requirements which can be translated into proper > decisions for both task placements and frequencies selections. > Other classes have a more simplified model which is essentially based on > the relatively simple concept of POSIX priorities. > > Such a simple priority based model however does not allow to exploit > some of the most advanced features of the Linux scheduler like, for > example, driving frequencies selection via the schedutil cpufreq > governor. However, also for non SCHED_DEADLINE tasks, it's still > interesting to define tasks properties which can be used to better > support certain scheduler decisions. > > Utilization clamping aims at exposing to user-space a new set of > per-task attributes which can be used to provide the scheduler with some > hints about the expected/required utilization for a task. > This will allow to implement a more advanced per-task frequency control > mechanism which is not based just on a "passive" measured task > utilization but on a more "active" approach. For example, it could be > possible to boost interactive tasks, thus getting better performance, or > cap background tasks, thus being more energy efficient. > Ultimately, such a mechanism can be considered similar to the cpufreq's > powersave, performance and userspace governor but with a much fine > grained and per-task control. > > Let's introduce a new API to set utilization clamping values for a > specified task by extending sched_setattr, a syscall which already > allows to define task specific properties for different scheduling > classes. > Specifically, a new pair of attributes allows to specify a minimum and > maximum utilization which the scheduler should consider for a task. > > Signed-off-by: Patrick Bellasi > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Tejun Heo > Cc: Rafael J. Wysocki > Cc: Vincent Guittot > Cc: Viresh Kumar > Cc: Paul Turner > Cc: Todd Kjos > Cc: Joel Fernandes > Cc: Steve Muckle > Cc: Juri Lelli > Cc: Dietmar Eggemann > Cc: Morten Rasmussen > Cc: linux-kernel@vger.kernel.org > Cc: linux-pm@vger.kernel.org > --- > include/linux/sched.h | 16 ++++++++ > include/uapi/linux/sched.h | 4 +- > include/uapi/linux/sched/types.h | 64 +++++++++++++++++++++++++++----- > init/Kconfig | 19 ++++++++++ > kernel/sched/core.c | 39 +++++++++++++++++++ > 5 files changed, 132 insertions(+), 10 deletions(-) > > diff --git a/include/linux/sched.h b/include/linux/sched.h > index 43731fe51c97..fd8495723088 100644 > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -279,6 +279,17 @@ struct vtime { > u64 gtime; > }; > > +enum uclamp_id { > + /* No utilization clamp group assigned */ > + UCLAMP_NONE = -1, > + > + UCLAMP_MIN = 0, /* Minimum utilization */ > + UCLAMP_MAX, /* Maximum utilization */ > + > + /* Utilization clamping constraints count */ > + UCLAMP_CNT > +}; > + > struct sched_info { > #ifdef CONFIG_SCHED_INFO > /* Cumulative counters: */ > @@ -649,6 +660,11 @@ struct task_struct { > #endif > struct sched_dl_entity dl; > > +#ifdef CONFIG_UCLAMP_TASK > + /* Utlization clamp values for this task */ > + int uclamp[UCLAMP_CNT]; > +#endif Seems a bit wasteful to me. Seems you need 2 values that are in the range 0..1024. Can we not do better with task_struct space usage? thanks! - Joel