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
