lkml.org 
[lkml]   [2008]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCH 0/4] CPUSET driven CPU isolation
Ingo Molnar wrote:
> * Paul Jackson <pj@sgi.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





\
 
 \ /
  Last update: 2008-02-28 21:27    [W:0.284 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site