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;
Date:   Fri, 4 Nov 2022 12:06:07 +0000
From:   Qais Yousef <qyousef@layalina.io>
To:     Joel Fernandes <joel@joelfernandes.org>
Cc:     Vincent Guittot <vincent.guittot@linaro.org>, 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
Subject: Re: [PATCH v7 6/9] sched/fair: Add sched group latency support
Message-ID: <20221104120607.feovsqj5wvzptkcp@airbuntu>
References: <CAKfTPtBJQOY7UUkm1=wvG18UWgLLiTW0dr3bTGUJY=siM_LLxQ@mail.gmail.com>
 <CD57BDD3-5919-48EC-992A-3879D8AA074F@joelfernandes.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CD57BDD3-5919-48EC-992A-3879D8AA074F@joelfernandes.org>
Precedence: bulk

On 11/04/22 06:55, Joel Fernandes wrote:

> >> I think the interface solves a different problem which is latency of task
> >> or cgroup wrt other group. Vincent, you are setting this for a “top app”
> >> group in android in your tests, and seeing improvement correct? AFAICS,
> >> this improvement comes because of lower latency
> > 
> > Yes Top app and display group
> > 
> >> during *same CPU* competition between different groups by juggling around
> >> the wakeup-preemption window -- which maybe is good for Android.
> >> 
> >> OTOH, the “prefer idle” flag in android that Qais is referring 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 -20
> > ?
> 
> Ah and forgot to reply about negative.
> 
> Maybe, but it’s still a horrible overload of the meaning of the value. I am
> not terribly against choosing negative value if there is consensus among
> everyone. Qais?

TBH I think the whole notion of 'nice' is confusing. From my experience talking
with some game developers they didn't know how to use nice values or what they
exactly mean. Given their target audience is a large diverse range of devices
with different spec, and that they can only lower it as increasing it requires
privilege; how to decide the right value to work reliably everywhere?

latency_nice might suffer from the same problem. But I don't have a better
alternative to suggest. I think that was the worrying input from Peter and
Thomas; these numbers could appear like magic crystal ball from users
perspective but I haven't seen any new discussion in spite my attempt to stir
it.

As we brought up in another email thread; I think CFS notion of priority could
be improved and it could lead to improve this problem by product. But this
won't address problems like load balance search times that were brought up as
part of this latency discussions in the past.

So short answer is I don't know :) I think the interface and use cases should
be discussed more still.


Thanks

--
Qais Yousef