On Thu, 2008-03-06 at 07:47 -0600, Paul Jackson wrote:
Likely; if for instance you'd want some unbound kernel threads to join
in that overlapping set, then perhaps that name would be badly chosen.
Although I'm not sure which unbound kernel threads would benefit from
such treatment.
Perhaps we're talking about something else here; how bad would it be to
require:
for irq in `cat /cgroup/boot/irqs` ; do echo $irq > /cgroup/irqs; done
be added to rc.local or fully replace your home-brew boot cpuset script?
Its basically an update for that script, giving the exact same semantics
to its user, but moving the larger part of it in-kernel.
Sure, but your application vendors will need to re-certify their
applications to run on new distros, sometimes even re-compile because
ABI changes and the like. Certainly providing a new script in the new
version certified for a new distro isn't too much work?
Assign a map of cpus where irqs will default into, and a way to
explicitly move them out of it.
So, yes, cgroups are perhaps awkward because they group tasks whereas
the current problem is grouping IRQs.
Because we're mapping them onto CPUs, cpusets came to mind.
The thing we 'need', is to provide named groups of irqs and for each
such a group specify a cpu mask that is appropriate.
Grouping them makes sense in that we want to make a functional division.
Some IRQs serve a system as a whole, others serve a subset. Typical
subsets could be a RT process space bounded to a cpu/mem domain.
Other usable subsets could be limiting the IRQs of node local network
and IO cards to the cpu/mem domain that runs the application that uses
them.
So we group irqs like:
system_on_nodes_1_2_and_3 (default)
big_io_app_on_nodes_2_and_3
rt_app_on_node_4
Where, again, you see a strong similarity to the cpu/mem divisions
already made by cpusets.
I understand its somewhat at odds with the hierarchical nature of the
<task, cpu/mem> mapping you currently have. But its not too far away
either.
Do you see what we want to do, and why our - perhaps misguided - choice
for cpusets? Creating a whole new cgroup controller is also weird
because we don't deal in tasks.
[ Aside from grouping existing IRQs we also want to provide a way to
designate a default group for new IRQs. But I think such functionality
will fall into place once we can agree on the rest.]
--
