Re: [PATCH 1/3] sched/isolation: Add HK_FLAG_SCHED to nohz_full

[Waiman Long]

On 9/4/24 09:04, Peter Zijlstra wrote:
> On Wed, Sep 04, 2024 at 02:44:26PM +0200, Frederic Weisbecker wrote:
> > > > I'm a bit scared about rule 1) because I know there are existing users of
> > > > nohz_full on multi-CPU domains... So I feel a bit trapped.
> > > As stated before, this is not a common use case.
> > Not sure and anyway it's not a forbidden usecase. But this is anyway outside
> > the scope of this patchset.
> Most crucially, it is a completely broken setup. It doesn't actually
> work well.
>
> Taking it away will force people to fix their broken. That's a good
> thing, no?
It will be hard to take it away without a good substitute. This is 
exactly what I am trying to accomplish with the dynamic CPU isolation work.

> > > The isolcpus boot option is deprecated, as stated in kernel-parameters.txt.
> > We should undeprecate it, apparently it's still widely used. Perhaps by people
> > who can't afford to use cpusets/cgroups.
> What is the actual problem with using cpusets? At the very least the
> whole nohz_full thing needs to be moved into cpusets so it isn't a fixed
> boot time thing anymore.
Right.
> > > My plan is to deprecate nohz_full as well once we are able to make dynamic
> > > CPU isolation via cpuset works almost as good as isolcpus + nohz_full.
> > You can't really deprecate such a kernel boot option unfortunately. Believe me
> > I wish we could.
> Why not? As I said, the only thing that's kept it around, and worse,
> made it more popular again, is this nohz_full nonsense. That never
> should've used isolcpus, but that's not something we can do anything
> about now.
>
> Rigid, boot time only things are teh suck.

Declaring a feature as being deprecated is the first step in the process 
of removing it. Users can still use a deprecated feature as the code is 
still there. The actual removal will be at least several releases later 
if not more.

Cheers,
Longman