Re: Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses)

[Andi Kleen <andi@firstfloor.org>]

> I was responding to a need you noticed to isolate memory nodes (such as
> from stray glibc pages placed by init or the shell running early
> scripts), not to the need to isolate CPUs:

Yes, but in practice (enough memory for bootup) isolating CPUs
is equivalent to isolating nodes. So isolcpus=... tended to work.

I occasionally recommended it to people because it was much easier
to explain than replacing init.

The perfect solution would be probably just fix it in init(8)
and make it parse some command line option that then sets up
the right cpusets.

But you asked for isolcpus=... use cases and I just wanted to describe
one.

> So perhaps it boils down to a question of which is easiest to do,
> the answer to which will vary depending on where you are in the food
> chain of distributions.  Here "easy" means least likely to break
> something else.  All these mechanisms are relatively trivial, until
> one has to deal with conflicting software packages, configurations and
> distributions, changing out from under oneself.

One solution would be to move isolcpus=/isonodes= into init(8) and make
sure it's always statically linked. But failing that keeping it in the
kernel is not too bad. It's certainly not a lot of code.

On the other hand if the kernel implemented a isolnodes=... it would
be possible to exclude those nodes from the interleaving the kernel
does at boot, which might be also beneficial and give slightly
more isolation.

-Andi