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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 4 Jun 2008 15:16:22 -0500
From:	Paul Jackson <pj@....com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	andi@...stfloor.org, maxk@...lcomm.com, ioe-lkml@...eria.de,
	sivanich@....com, a.p.zijlstra@...llo.nl,
	linux-kernel@...r.kernel.org, kernel@...ivas.org, dfults@....com,
	devik@....cz, dino@...ibm.com, emmanuel.pacaud@...v-poitiers.fr,
	deweerdt@...e.fr, mingo@...e.hu, colpatch@...ibm.com,
	nickpiggin@...oo.com.au, rostedt@...dmis.org, oleg@...sign.ru,
	paulmck@...ibm.com, menage@...gle.com, rddunlap@...l.org,
	suresh.b.siddha@...el.com, tglx@...utronix.de
Subject: Re: Inquiry: Should we remove "isolcpus= kernel boot option? (may
 have realtime uses)

pj wrote:
> We (SGI) routinely handle that need with a custom init program,
> invoked with the init= parameter to the booting kernel, ...

Andi replied:
> There are no additional changes needed, but you must admit that isolcpus
> is a much more elegant solutation for this problem than hijacking init.

While I cannot claim that hijacking init is elegant, our gentle
readers are at risk of losing the context here.

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:

Andi had written earlier:
> One example I've seen in the past is that someone wanted to isolate a node
> completely from any memory traffic to avoid performance disturbance
> for memory intensive workloads.

Granted, this might be a distinction without a difference, because on
the very lightly loaded system seen at boot, local node memory placement
will pretty much guarantee that the memory is placed on the nodes next
to the CPUs on which init or its inelegant replacements are run.

You noted this yourself, when you wrote:
> Given the use case wants more a "isolnodes", but given that there
> tends to be enough free memory at boot "isolcpus" tended to work.

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.

That is, it can be desirable to have multiple mechanisms, so that the
various folks independently needing to manipulate such placement can
minimize stepping on each others feet.  By using the rarely hacked init=
mechanism for SGI software addons, we don't interfere with those who
are using the more common isolcpus= mechanism for such purposes as
offlining a bad CPU.

In sum, I suspect we agree that we have enough mechanisms, and don't
need an isolnodes as well.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.940.382.4214
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/