On 04.05.2012 [23:01:34 +0200], Peter Zijlstra wrote: > On Fri, 2012-05-04 at 13:49 -0700, Nishanth Aravamudan wrote: > > I think it's ok for hotplug to be destructive. But I guess I'm not > > entirely sure why cpusets can't retain user-inputted > > configuration/policy information even while destroying things currently? > > And re-instating that policy if possible in the future? > > Two issues here: > - if you retain it for cpuset but not others that's confusing (too); That's a good point. Related, possibly counter-example, and perhaps I'm wrong about it. When we hot-unplug a CPU, and a task's scheduler affinity (via sched_setaffinity) refers to that CPU only, do we kill that task? Can you sched_setaffinity a task to a CPU that is offline (alone or in a group of possible CPUs)? Or is it allowed to run anywhere? Do we destroy its affinity policy when that situation is run across? Or do we restore the task to the CPU again when we re-plug it? I'm just curious about what the kernel does here and you probably know off the top of your head :) It feels like a similar situation. > - we never retain anything, if you unload a module you loose all state > that was associated with it too. What makes this special? Another good point. I would think if we were talking about unmounting cpusetfs altogether then what you say would correspond. But I feel like there is some distinction between module unloading (and remembering information about the module in question, I assume you mean things like module parameters) and cpu hotplug (and remembering information about cpuset configuration, which isn't necessarily directly related). I don't have good answers to either of your points off the top of my head -- but even if we say that "hey, userspace, you're dumb, get over it", it feels like there could be more that we could do here. It seems wrong to make every cpuset user (presuming there are more than just libvirt & SGI) scan regularly for empty cpusets (I'm operating under the assumption that the person setting up the cpuset configuration may not be the same person that does the CPU hotplug operation). Thanks, Nish -- Nishanth Aravamudan <nacc@xxxxxxxxxx> IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
