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]
Message-Id: <20080228031710.3405e405.pj@sgi.com>
Date:	Thu, 28 Feb 2008 03:17:10 -0600
From:	Paul Jackson <pj@....com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	a.p.zijlstra@...llo.nl, tglx@...utronix.de, oleg@...sign.ru,
	rostedt@...dmis.org, maxk@...lcomm.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCH 0/4] CPUSET driven CPU isolation

Ingo wrote:
>  The "bootup" cpuset is just 
> a convenience container to handle everything that the box booted up 
> with, and then we can shrink it (without having to enumerate every PID 
> and every irq and other resource explicitly) to make place for other 
> cpusets.

I'm not quite sure of what you're thinking here; rather I'm just
bouncing off the sound of your words.

But your words sound alot like what we at SGI call a 'boot' cpuset.

Our big honkin NUMA customers, who are managing most of the system
either for a few dedicated, very-important jobs, and/or under a
batch scheduler, need to leave a few nodes to run the classic Unix
load such as init, cron, assorted daemons and the admins login shell.

So we provide them some init script mechanisms that make it easy to
set this up, which includes moving every task (not many at the low
numbered init script time this runs) that isn't pinned (doesn't have
a restricted Cpus_allowed) into the boot cpuset, conventionally
named /dev/cpuset/boot.

-- 
                  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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ