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: <cover.1686239016.git.bristot@kernel.org> <bd9977efff8cc3e002c4b2db02f611167905a99f.1686239016.git.bristot@kernel.org>
 <CAEXW_YT0DmvQo_gfCq5uzpZpf36HmfzXozo9+=sYJp-hZx4qTQ@mail.gmail.com>
 <b2cd0072-d226-4adb-ddf5-958d9635f881@kernel.org> <CAEXW_YR9Tfw5KyFU7TQtYE02k+DpaMXH=osx9Ws5w_j1YpHxhg@mail.gmail.com>
 <841849b5-1f9c-4f0e-2de8-1da278256888@kernel.org> <CAEXW_YQ7vEakRcJgva_PYEnsj4ZLafH-pXQiJ5STCkM7dQAttg@mail.gmail.com>
 <4849295d-9aef-836f-0e5f-063e2075380a@kernel.org> <ZInLcNqGpLCw8xsn@localhost.localdomain>
In-Reply-To: <ZInLcNqGpLCw8xsn@localhost.localdomain>
From:   Joel Fernandes <joel@joelfernandes.org>
Date:   Wed, 14 Jun 2023 14:27:38 -0400
Message-ID: <CAEXW_YTea1LdPkcwPDw5wdvM+205k4eFfaM_DwhvGKB8rCn_Ug@mail.gmail.com>
Subject: Re: [RFC PATCH V3 6/6] sched/fair: Implement starvation monitor
To:     Juri Lelli <juri.lelli@redhat.com>
Cc:     Daniel Bristot de Oliveira <bristot@kernel.org>,
        Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
        Valentin Schneider <vschneid@redhat.com>,
        linux-kernel@vger.kernel.org,
        Luca Abeni <luca.abeni@santannapisa.it>,
        Tommaso Cucinotta <tommaso.cucinotta@santannapisa.it>,
        Thomas Gleixner <tglx@linutronix.de>,
        Vineeth Pillai <vineeth@bitbyteword.org>,
        Shuah Khan <skhan@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Jun 14, 2023 at 10:15=E2=80=AFAM Juri Lelli <juri.lelli@redhat.com>=
 wrote:
>
> Hey,
[..]
> > By postponing the enqueue/replanishment of the DL server here, we are f=
ixing the
> > problem in a practical way, that works without breaking existing useful=
 properties &
> > use-cases.
>
> In my understanding, if we simply postpone actual activation of the DL
> server up to the point it really needs to boost/run for giving CFS tasks
> some breath (the infamous 0-laxity :), we save RT tasks from useless
> interruptions and still can keep EDF/CBS working w/o much changes.
>
> It looks like a low hanging fruit, small improvement on what we have toda=
y
> than doesn't prevent us for implementing more complex features (i.e., ful=
l
> blown hierarchical scheduling, alternative schedulers) in the future if
> the need arises.

Agreed, thanks!

 - Joel