Re: IRQ affinities
From: Max Krasnyanskiy
Date: Tue May 20 2008 - 21:15:20 EST
Paul Jackson wrote:
That's a new feature; and its quite common that new features require
It's common for new features to require code changes to take advantage
of the new features.
It's less desirable that taking advantage of such new features breaks
existing, basically unrelated, code.
My gut sense is that, in a misguided effort to find a "simple" answer
to irq distribution, we (well, y'all) are trying to attach this
feature to cpusets or cgroups.
Let me ask a different question:
What solutions would you (Max, Peter, Ingo, lurkers, ...) be
suggesting for this 'IRQ affinity' problem if cpusets and
cgroups didn't exist in any form whatsoever?
As Peter explained I'm focusing on the "CPU isolation" aspect. ie Shielding a
CPU (or a set of CPUs) from various kernel activities (load balancing, soft
and hard irq handling, workqueues, etc).
For the IRQs specifically all I need is to be able to tell the kernel to not
route IRQs to certain CPUs. That's mostly works already via
/proc/irq/N/smp_affinity, the problem is dynamically allocated irqs because
/proc/irq/N directory does not exist until those IRQs are allocated/enabled.
Originally I introduced global cpu_isolated_map. IRQ code was using that map
to exclude CPU(s) from IRQ routing. What I realized now is that all I need is
/proc/irq/default_smp_affinity. In other words I just need to export default
mask used by the IRQ layer. I think this makes sense regardless of what cpuset
based solution we'll come up with.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/