Hi Keir,
I used -unstable tree and noticed the following:
cat /proc/interrupts | grep eth
18: 7580 0 0 0 Phys-irq eth0
19: 1 0 0 0 Phys-irq eth1
20: 1982 78 117 0 Phys-irq peth2
21: 18 0 0 1129 Phys-irq eth3
22: 67 1077 0 0 Phys-irq eth4
23: 12 1135 0 0 Phys-irq eth5
cat /proc/irq/20/smp_affinity
00000001
echo 2 > /proc/irq/20/smp_affinity [...works..]
echo 4 > /proc/irq/20/smp_affinity [...works..]
echo 8 > /proc/irq/20/smp_affinity [...works..]
But, a cumulative does not work...meaning...
echo 3>
echo 5>
echo f> etc.... do not work.
Is that a bug or is it by design?
thanks,
harish
On 6/11/06, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
On 10 Jun 2006, at 17:58, harish wrote:
> echo "2" > /proc/irq/23/smp_affinity does not seem to change the
> value in smp_affinity
> cat /proc/irq/23/smp_affinity still shows 0f
>
> Could there some bug or configuration problem that you can think of?
It was a bug, which I've just fixed in -unstable and -testing staging
trees. When that reaches the public trees you should find that writing
to smp_affinity has the usual effect, but note:
1. As when running on native, a request to change affinity is not
processed until the next interrupt occurs for that irq. If the
interrupt rate on that irq is very low, you may be able to observe old
value in smp_affinity before it is changed.
2. You cannot change affinity of CPU-local interrupts (timer, resched,
callfunc). Requests to do so are silently ignored.
3. If you try to set a multi-cpu cpumask for affinity, it will be
changed to a single-cpu cpumask automatically. Linux-on-Xen does not
automatically balance irq load across cpus -- that has to be done by a
user-space daemon (e.g., irqbalance).
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel