linux-kernel - Re: + sched-force-sbin-init-off-isolated-cpus.patch added to -mm tree

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>] [day] [month] [year] [list]

Message-Id: <20060727221900.d87afdcc.pj@sgi.com>
Date:	Thu, 27 Jul 2006 22:19:00 -0700
From:	Paul Jackson <pj@....com>
To:	linux-kernel@...r.kernel.org
Cc:	akpm@...l.org, mm-commits@...r.kernel.org, npiggin@...e.de,
	mingo@...e.hu, sivanich@....com
Subject: Re: + sched-force-sbin-init-off-isolated-cpus.patch added to -mm
 tree

Nick wrote:
> Force /sbin/init off isolated cpus (unless every CPU is specified as an
> isolcpu).

For our big honkin NUMA iron SGI customers, who are serious about this
sort of thing, we actually already do this, entirely in user space.  I
use the init= kernel command line boot option to run a pre-init program,
that sets up a configurable (by a config file in /etc) cpuset, then
exec's the real init in that cpuset.  This feature is known to SGI
customers as the "bootcpuset."

But Nick's patch looks ok to me.  It seems harmless enough for our NUMA
power users - as the bootcpuset they configured will just override what
Nick's code did a few milliseconds (to read the pre-init executable off
the disk) earlier, harmlessly.  Meanwhile, the remaining (and likely
vast majority of) isolcpu users will get the behaviour they prefer.

Acked-by: Paul Jackson <pj@....com>

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.925.600.0401
-
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/