Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220311161406.23497-1-vincent.guittot@linaro.org>
 <20220311161406.23497-7-vincent.guittot@linaro.org> <CABk29Ns1=2kc3JAESx_Ce7PP86KqiDA4O9K+vaOLZbKfq_XVaQ@mail.gmail.com>
In-Reply-To: <CABk29Ns1=2kc3JAESx_Ce7PP86KqiDA4O9K+vaOLZbKfq_XVaQ@mail.gmail.com>
From:   Vincent Guittot <vincent.guittot@linaro.org>
Date:   Tue, 15 Mar 2022 18:07:37 +0100
Message-ID: <CAKfTPtAZVred+GqR5Uj0eGeawhhbSQR5+N4GFvtkM-KsYrcSpw@mail.gmail.com>
Subject: Re: [RFC 6/6] sched/fair: Add sched group latency support
To:     Josh Don <joshdon@google.com>
Cc:     Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Juri Lelli <juri.lelli@redhat.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Benjamin Segall <bsegall@google.com>,
        Mel Gorman <mgorman@suse.de>,
        linux-kernel <linux-kernel@vger.kernel.org>, parth@linux.ibm.com,
        Qais Yousef <qais.yousef@arm.com>,
        "Hyser,Chris" <chris.hyser@oracle.com>,
        Pavan Kondeti <pkondeti@codeaurora.org>,
        Valentin Schneider <Valentin.Schneider@arm.com>,
        patrick.bellasi@matbug.net, David.Laight@aculab.com,
        Paul Turner <pjt@google.com>, pavel@ucw.cz,
        Tejun Heo <tj@kernel.org>,
        Dhaval Giani <dhaval.giani@oracle.com>, qperret@google.com,
        Tim Chen <tim.c.chen@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, 15 Mar 2022 at 01:59, Josh Don <joshdon@google.com> wrote:
>
> On Fri, Mar 11, 2022 at 8:15 AM Vincent Guittot
> <vincent.guittot@linaro.org> wrote:
> >
> [snip]
> >
> >  static struct cftype cpu_legacy_files[] = {
> > @@ -10649,6 +10673,11 @@ static struct cftype cpu_legacy_files[] = {
> >                 .read_s64 = cpu_idle_read_s64,
> >                 .write_s64 = cpu_idle_write_s64,
> >         },
> > +       {
> > +               .name = "latency",
> > +               .read_s64 = cpu_latency_read_s64,
> > +               .write_s64 = cpu_latency_write_s64,
> > +       },
> >  #endif
> >  #ifdef CONFIG_CFS_BANDWIDTH
> >         {
> > @@ -10866,6 +10895,18 @@ static struct cftype cpu_files[] = {
> >                 .read_s64 = cpu_idle_read_s64,
> >                 .write_s64 = cpu_idle_write_s64,
> >         },
> > +       {
> > +               .name = "latency",
> > +               .flags = CFTYPE_NOT_ON_ROOT,
> > +               .read_s64 = cpu_latency_read_s64,
> > +               .write_s64 = cpu_latency_write_s64,
> > +       },
> > +       {
> > +               .name = "latency.nice",
> > +               .flags = CFTYPE_NOT_ON_ROOT,
> > +               .read_s64 = cpu_latency_nice_read_s64,
> > +               .write_s64 = cpu_latency_nice_write_s64,
> > +       },
>
> Something I considered when adding cpu.idle was that negative values
> could be used to indicate increasing latency sensitivity. Folding the
> above latency property into cpu.idle could help consolidate the
> "latency" behavior, especially given that it shouldn't really be
> possible to configure an entity as both latency sensitive and idle.

The range of latency nice is [-19:20] and it doesn't touch on the
weight whereas sched_idle behavior impacts both the shares and the
preemption so I was afraid of possible confusion with what latency
nice is doing