Messages in this thread | | | Subject | Re: boot cgroup questions | From | Peter Zijlstra <> | Date | Fri, 09 May 2008 12:45:26 +0200 |
| |
On Mon, 2008-04-14 at 13:39 -0500, Paul Jackson wrote: > Max wrote: > > I mean you guys were talking about how wonderful > > and flexible cpusets are, but we cannot seem to use the flexibility because > > the apps are designed for a flat layout > > No. Not flat. Not at all flat. > > We routinely and normally have an interesting hierarchy of cpusets > below /dev/cpuset. However that hierarchy is determined by the > nesting of subsets of the nodes (CPUs and/or Memory) on the system. > > These subsets of nodes in the /dev/cpuset hierarchy may well map > nicely into the subsets of CPUs that can receive a particular set > of IRQs, however that map is not bijective. Of particular interest > here, it's not injective, meaning that multiple cpusets might and > will commonly receive the same set of IRQs. You can force this map > to be injective by elaborating the cpuset hierarchy to reflect both > this new assignment of IRQs and the (CPU and/or Memory) node subset > hiearchy that it currently reflects, but that will break code that > was expecting the directory tree below /dev/cpuset to directly and > only reflect the node hierarchy. > > In less mathematically obtuse wording, sure you can add more directory > layers below /dev/cpuset, to handle IRQ assignments, but that will > break code that was expecting the /dev/cpuset directory tree to only > reflect the nesting of (CPU and/or Memory) nodes.
Sorry for being rather late to the game - other stuff keeps me from doing anything much here :-(.
Anyway, the current applications don't support IRQ assingment anyway. That's a new feature; and its quite common that new features require code changes.
So I'm not seeing the problem - don't change code and stuff works as before - change code and you get new stuff.
So I'm arguing in favour of the IRQs as tasks idea that might need extra hierarchy levels.
| |