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: <20221028093403.6673-1-vincent.guittot@linaro.org>
 <20221028093403.6673-7-vincent.guittot@linaro.org> <20221101192848.pjns3um7dnrwrk5p@airbuntu>
 <CAKfTPtA=vJQA_=6Un1CqwzMUaOxMeFGTKUZnj8qyqvqmSdYBAg@mail.gmail.com>
 <20221103142732.m5ibwkuymvhcdxkn@airbuntu> <CAKfTPtDu=c-psGnHkoWSPRWoh1Z0VBBfsN++g+krv4B1SJmFjg@mail.gmail.com>
 <CAEXW_YQd2y9=RHw3Sge7ghnhBz0AyR+B-U4zG10LXuSbg5bGSA@mail.gmail.com> <CAKfTPtBJQOY7UUkm1=wvG18UWgLLiTW0dr3bTGUJY=siM_LLxQ@mail.gmail.com>
In-Reply-To: <CAKfTPtBJQOY7UUkm1=wvG18UWgLLiTW0dr3bTGUJY=siM_LLxQ@mail.gmail.com>
From:   Joel Fernandes <joel@joelfernandes.org>
Date:   Fri, 4 Nov 2022 10:48:42 +0000
Message-ID: <CAEXW_YTcmbPg+UCacb4Vy0LeYuorT-yECoa39pqtw5wPUkzsvQ@mail.gmail.com>
Subject: Re: [PATCH v7 6/9] sched/fair: Add sched group latency support
To:     Vincent Guittot <vincent.guittot@linaro.org>
Cc:     Qais Yousef <qyousef@layalina.io>, mingo@redhat.com,
        peterz@infradead.org, juri.lelli@redhat.com,
        dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com,
        mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com,
        linux-kernel@vger.kernel.org, parth@linux.ibm.com,
        qais.yousef@arm.com, chris.hyser@oracle.com,
        patrick.bellasi@matbug.net, David.Laight@aculab.com,
        pjt@google.com, pavel@ucw.cz, tj@kernel.org, qperret@google.com,
        tim.c.chen@linux.intel.com, joshdon@google.com, timj@gnu.org,
        kprateek.nayak@amd.com, yu.c.chen@intel.com,
        youssefesmat@chromium.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Nov 4, 2022 at 10:37 AM Vincent Guittot
<vincent.guittot@linaro.org> wrote:
[...]
> > during *same CPU* competition between different groups by juggling
> > around the wakeup-preemption window -- which maybe is good for
> > Android.
> >
> > OTOH, the =E2=80=9Cprefer idle=E2=80=9D flag in android that Qais is re=
ferring to,
> > will need a completely different method as I cannot see how a nice
> > value can communicate that (that can complement Vincent's changes
> > here). And it will need to have a per-task interface as well. We have
>
> Why a negative latency_nice value condition can't be used ? or latency -2=
0  ?

That's overloading the meaning of a value, the whole nice thing is
supposed to be "relative to something". So you are being nice to
something else. Here -20 means you are not being nice. But in fact you
are, because you are avoiding hurting something else by going to an
idle CPU. So it becomes really weird.

Also, why would -19 or -18 not be a value instead to cause wakeup to
prefer an idle CPU? It confuses the user on how to choose value and we
should refrain from that IMHO.