Re: [PATCH 1/2] sched/isolation: Merge individual nohz_full features into a common housekeeping flag

[Waiman Long]

On 2/7/23 07:59, Michal Koutný wrote:
> On Tue, Feb 07, 2023 at 12:49:41PM +0100, Frederic Weisbecker <frederic@xxxxxxxxxx> wrote:
> > But what do we need these annotations for? The only outcome I've ever
> > seen with these is that it confuses everyone.
> Take that as a note of a lone actor then who found it useful documenting
> relations between various parts of the code.
>
> > This way I can add the support for each part smoothly.
> Yeah, that makes sense.
>
> > For example first patch moves HK_TYPE_TIMER to HK_TYPE_KERNEL_NOISE
> > and unbound timers are supported by cpuset.kernel_noise, second patch
> > moves HK_TYPE_WQ to HK_TYPE_KERNEL_NOISE and unbound workqueues are
> > supported by cpuset.kernel_noise, etc until all of them turned by
> > nohz_full= are supported...
> So does this mean you'll re-introduce the finer grained HK_* flags
> again?
>
> The idea (not only mine?) is that this would extend
> cpuset.cpus.partition that only allows HK_TYPE_DOMAIN analogy. The
> mapping to individual flags may not be exposed to users. The graduality
> could be achieved by adding more flags under user_exposed_term.
>
> Just to be on the same page -- that's how I understand it, the original
> HK_* resolution turned out impractical for users and that's why the
> direction is towards some loose combinations representing user
> intentions. Is that right?

What I am envisioning is to have additional isolation attributes to an 
isolated partition that correspond to what a user can specify on the 
kernel command line today. That requires the minimal amount of learning 
from the user community. Any finer grained separation of isolation 
features will just confuse user. I don't see a problem with a generic 
HK_TYPE_KERNEL_NOISE that gets enabled when an attribute that correspond 
to nohz_full is used.

Cheers,
Longman