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: <47C71857.5060606@qualcomm.com>
Date:	Thu, 28 Feb 2008 12:23:51 -0800
From:	Max Krasnyansky <maxk@...lcomm.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Paul Jackson <pj@....com>, a.p.zijlstra@...llo.nl,
	tglx@...utronix.de, oleg@...sign.ru, rostedt@...dmis.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCH 0/4] CPUSET driven CPU isolation

Ingo Molnar wrote:
> * Paul Jackson <pj@....com> wrote:
> 
>>> i've queued up your patches in sched-devel.git
>> Before this patchset gets too far, I'd like to decide on whether to 
>> adapt my suggestion to call that per-cpuset flag 'cpus_system' (or 
>> anything else with 'cpu' in it, perhaps 'system_cpus' would be more 
>> idiomatic), rather than the tad too generic 'system'.
> 
> yeah. In fact i'm not at all sure this is really a "system" thing - it's 
> more of a "bootup" default.
> once the system has booted up and the user is in a position to create 
> cpusets, i believe the distinction and assymetry between any bootup 
> cpuset and the other cpusets should vanish. 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.
> 
> maybe it's even more idomatic to call it "set0" and just create a 
> /dev/cpuset/set0/ directory for it and making it an explicit cpuset - 
> instead of the hardcoded /dev/cpusets/system thing? Do you have any 
> established naming scheme for cpusets that we could follow here?

I think that is a separate thing. Bootup default is one thing and being able
to explicitly allow/disallow kernel activity on a CPU(s) is another.

I think "boot" or "set0" makes perfect sense. In fact that was the first thing
I noticed when I started playing with it. ie Even if I just wanted to isolated
 one cpu I now need to create a cpuset for the other cpus and move all the
tasks there explicitly. It'd be very useful if it happens by default.

Max



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