Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
Message-ID: <c30367d351c821b13c2bdd9d680388d244fa74c5.camel@gmx.de>
Subject: Re: [PATCH 0/2] sched/eevdf: sched_attr::sched_runtime slice hint
From:   Mike Galbraith <efault@gmx.de>
To:     Qais Yousef <qyousef@layalina.io>
Cc:     peterz@infradead.org, mingo@kernel.org,
        linux-kernel@vger.kernel.org, vincent.guittot@linaro.org,
        juri.lelli@redhat.com, dietmar.eggemann@arm.com,
        rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
        bristot@redhat.com, corbet@lwn.net, chris.hyser@oracle.com,
        patrick.bellasi@matbug.net, pjt@google.com, pavel@ucw.cz,
        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, joel@joelfernandes.org,
        tglx@linutronix.de, daniel.m.jordan@oracle.com
Date:   Wed, 20 Sep 2023 06:02:17 +0200
In-Reply-To: <20230919210851.ktzi7ogxs3punger@airbuntu>
References: <20230915124354.416936110@noisy.programming.kicks-ass.net>
         <20230916213316.p36nhgnibsidoggt@airbuntu>
         <5bec3f08b4251c770545b59ede8fc4820c8d685b.camel@gmx.de>
         <20230919210851.ktzi7ogxs3punger@airbuntu>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:q8OgTkTdrbo=;1IX6w5Ql1U8Wo0QOMipyMzTs4ox
 V1GAWsLpTGE1nz7uu/WPT8CmgBhFJNRCjGbLcdZWYHKtzZepGiid8Dq499VeX22u/DpidEpOV
 KeQq9ux1S8zH55pScCNIvBAA7BODRcBB4JFQnZVjYF+gSR2h00ejMxAmZ45O8Hwucj8b616yF
 hpcmjHGnsyedudtx7mLmIG8l1UyLO4TW3BCKwTt5H/9/3DXjbp0EY1ONVMNCXM4Q3TLczSkwp
 sIBP7g13k3QAxGoecMz1G13tkglqejdjabDBrlrZR0c1HiewDk9z8WZRhKwABSScucNxb5uF4
 I/QtKXNVTz/qboSvtrGPXLCO3bZRuQqwgs3VNi6vExDOq3R4KhxHfchz1Njxs8PHbpEOHB6Z9
 KieZO/vrGREZ1vo5OtPleOieTkE88CdVE742Q7h8ogITCkvPJVgFPpphdL9cZtDnKOl8cytRQ
 qxVYQ8zrLYLWJZePzSKhOYWTtJ5TJ1n1Ns6gyEjDij1cp5dyHly6r5Fo6PfuVsTM3ACpOHhKm
 P2iS/e0bUqoNxmQAD2wnnPkP/nQiZjnet3qV9jginEAqDO6ktTfCJwo+qba3HIBi2x2puF4fF
 wtvyMF4MG+m0T370NxjxlzEbfvoCMgBhgSu/7+C7y/GRlcrUmRGdBVyffnQsnd2SIZyUAPtJ+
 wtER7Zn+SfgJntvIMcH87W4YlcU2WBdD33n0ZMQmz7nX/xZ6RqkqBLlEiJ5YHSmTWkFi5TDzX
 366vDRFWr1qe5rxZzPrXt3MGlhBSVpM+pCdPBD7vqwtFj96PprcS90ZW/3VFHq+xePL+MGKBQ
 oxtmweCJjllJaZ5UQyhUeWvx3f5hCKAtpUFbxQ/S50w13/xzMAAfEtZijR+iwFik0u4ntAScd
 jM65+PORQjwz2AO42+dCqLSAe5khhbbF3qtoK6FeXMWTfiwK7D/YkAH3o1vCsQMXODcwNlz5a
 VElJ/SRZK0md/Xp/8EGm/YW11rQ=
Precedence: bulk

On Tue, 2023-09-19 at 22:08 +0100, Qais Yousef wrote:
> On 09/18/23 05:43, Mike Galbraith wrote:
> > On Sat, 2023-09-16 at 22:33 +0100, Qais Yousef wrote:
> > >
> > > Example of conflicting requirements that come across frequently:
> > >
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A01. Improve wake up l=
atency without for SCHED_OTHER. Many tasks
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 end up =
using SCHED_FIFO/SCHED_RR to compensate for this
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 shortco=
ming. RT tasks lack power management and fairness and
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 can be =
hard and error prone to use correctly and portably.
> >
> > This bit appears to be dealt with about as nicely as it can be in a
> > fair class by the latency nice patch set, and deals with both
> > individual tasks and groups thereof, ie has cgroups support.
>
> AFAIU the latency_nice is no longer going forward. But I could be mistak=
en.

Effectively it is, both making the same request under the hood, the
difference being trade negotiation idiom.

I took both to try out for no particularly good reason.  The only thing
silly looking in the result is one clipping at OMG the other at OMFG.

> > All three of those make my eyebrows twitch mightily even in their not
> > well defined form: any notion of applying badges to identify groups of
> > tasks would constitute creation of yet another cgroups.
>
> cgroups require root privilege. And it is intended for sysadmins to spli=
t
> system resources between apps. It doesn't help an app to describe the
> relationship between its tasks. Nor any requirements for them to do thei=
r job
> properly. But rather impose something on them regardless of what they wa=
nt.

The whys and wherefores are clear.  I suspect that addition of another
task group interface with conflicting scheduling parameters, policies,
hopes and/or prayers to be dealt with at each and every level of the
existing hierarchy is going to be hard to sell, but who knows, maybe
that skeleton looks more attractive to maintainers than it does to me.
I suppose we'll find out once you hang some meat on it.

	-Mike