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;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Joel Fernandes <joel@joelfernandes.org>
Mime-Version: 1.0 (1.0)
Subject: Re: Sum of weights idea for CFS PI
Date:   Sat, 8 Oct 2022 11:04:52 -0400
Message-Id: <0BFD3887-60A2-4C74-9D37-49B7B6E64299@joelfernandes.org>
References: <CALUeGD0OP4ZqDFcT10=ih40tGsm9gjjno7NP_Jwd1RxiUJZ0CQ@mail.gmail.com>
Cc:     Qais Yousef <qais.yousef@arm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>, juri.lelli@redhat.com,
        vincent.guittot@linaro.org,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Thomas Gleixner <tglx@linutronix.de>, bristot@redhat.com,
        clark.williams@gmail.com, bigeasy@linutronix.de,
        "Paul E. McKenney" <paulmck@kernel.org>
In-Reply-To: <CALUeGD0OP4ZqDFcT10=ih40tGsm9gjjno7NP_Jwd1RxiUJZ0CQ@mail.gmail.com>
To:     Youssef Esmat <youssefesmat@google.com>
Precedence: bulk


> On Oct 6, 2022, at 3:40 PM, Youssef Esmat <youssefesmat@google.com> wrote:=

>=20
[..]
>>=20
>>> Anyway - just trying to explain how I see it and why C is unlikely to be=
 taking
>>> too much time. I could be wrong. As Youssef said, I think there's no
>>> fundamental problem here.
>>=20
>> I know on Android where they use smaller HZ, the large tick causes
>> lots of problems for large nice deltas. Example if a highly niced task
>> was to be preempted for 1ms, and preempts instead at 3ms, then the
>> less-niced task will not be so nice (even less nice than it promised
>> to be) any more because of the 2ms boost that the higher niced task
>> got. This can lead the the sched_latency thrown out of the window. Not
>> adjusting the weights properly can potentially make that problem much
>> worse IMO.
>=20
> Once C releases the lock it should get adjusted and A will get
> adjusted also regardless of tick. At the point we adjust the weights
> we have a chance to check for preemption and cause a reschedule.

Yes but the lock can be held for potentially long time (and even user space l=
ock). I=E2=80=99m more comfortable with Peter=E2=80=99s PE patch which seems=
 a more generic solution, than sum of weights if we can get it working. I=E2=
=80=99m studying Connor=E2=80=99s patch set now=E2=80=A6

> If C doesn't release the lock quickly (hopefully rare), it should
> continue to run at the adjusted weight since it is still blocking A.

We can=E2=80=99t depend on rare. Even one bad instance is a fail. So if lock=
 holder and releaser go crazy, we can=E2=80=99t destabilize the system. Afte=
r all, this is CFS and fairness should not be broken, even if rarely.

Thanks.


>=20
>>=20
>> Thanks.