* smp_affinity, MSI-X and 2.6.21.1
@ 2007-05-07 20:53 Rick Jones
2007-05-07 23:07 ` Arjan van de Ven
2007-05-09 10:35 ` Andi Kleen
0 siblings, 2 replies; 7+ messages in thread
From: Rick Jones @ 2007-05-07 20:53 UTC (permalink / raw)
To: Linux Network Development list
Folks -
Is it a bug, or a feature that after changing a device's smp_affinity via echo
"N" >> /proc/irq/M/smp_affinity that the new mask isn't visible via cat
/proc/irq/M/smp_affinity until after actual interrupts are taken?
rick jones
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: smp_affinity, MSI-X and 2.6.21.1
2007-05-07 20:53 smp_affinity, MSI-X and 2.6.21.1 Rick Jones
@ 2007-05-07 23:07 ` Arjan van de Ven
2007-05-08 0:09 ` Rick Jones
2007-05-09 10:35 ` Andi Kleen
1 sibling, 1 reply; 7+ messages in thread
From: Arjan van de Ven @ 2007-05-07 23:07 UTC (permalink / raw)
To: Rick Jones; +Cc: Linux Network Development list
On Mon, 2007-05-07 at 13:53 -0700, Rick Jones wrote:
> Folks -
>
> Is it a bug, or a feature that after changing a device's smp_affinity via echo
> "N" >> /proc/irq/M/smp_affinity that the new mask isn't visible via cat
> /proc/irq/M/smp_affinity until after actual interrupts are taken?\
that's known and expected behavior
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: smp_affinity, MSI-X and 2.6.21.1
2007-05-07 23:07 ` Arjan van de Ven
@ 2007-05-08 0:09 ` Rick Jones
0 siblings, 0 replies; 7+ messages in thread
From: Rick Jones @ 2007-05-08 0:09 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Linux Network Development list
Arjan van de Ven wrote:
> On Mon, 2007-05-07 at 13:53 -0700, Rick Jones wrote:
>
>>Folks -
>>
>>Is it a bug, or a feature that after changing a device's smp_affinity via echo
>>"N" >> /proc/irq/M/smp_affinity that the new mask isn't visible via cat
>>/proc/irq/M/smp_affinity until after actual interrupts are taken?\
>
>
> that's known and expected behavior
well, expected by those in the know anyway :)
thanks.
rick jones
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: smp_affinity, MSI-X and 2.6.21.1
2007-05-09 10:35 ` Andi Kleen
@ 2007-05-09 9:46 ` David Miller
2007-05-09 11:50 ` Andi Kleen
0 siblings, 1 reply; 7+ messages in thread
From: David Miller @ 2007-05-09 9:46 UTC (permalink / raw)
To: andi; +Cc: rick.jones2, netdev
From: Andi Kleen <andi@firstfloor.org>
Date: 09 May 2007 12:35:29 +0200
> Rick Jones <rick.jones2@hp.com> writes:
>
> > Folks -
> >
> > Is it a bug, or a feature that after changing a device's smp_affinity
> > via echo "N" >> /proc/irq/M/smp_affinity that the new mask isn't
> > visible via cat /proc/irq/M/smp_affinity until after actual interrupts
> > are taken?
>
> Intel chipsets can only safely update affinity during interrupt processing.
> You see a side effect of the code implementing this restriction.
That's true, but we are talking about software state so in some sense
it might be better that the affinity-to-be is reported to the user in
this case.
Delayed register updates are an implementation detail the user does
not need to know about here.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: smp_affinity, MSI-X and 2.6.21.1
2007-05-07 20:53 smp_affinity, MSI-X and 2.6.21.1 Rick Jones
2007-05-07 23:07 ` Arjan van de Ven
@ 2007-05-09 10:35 ` Andi Kleen
2007-05-09 9:46 ` David Miller
1 sibling, 1 reply; 7+ messages in thread
From: Andi Kleen @ 2007-05-09 10:35 UTC (permalink / raw)
To: Rick Jones; +Cc: Linux Network Development list
Rick Jones <rick.jones2@hp.com> writes:
> Folks -
>
> Is it a bug, or a feature that after changing a device's smp_affinity
> via echo "N" >> /proc/irq/M/smp_affinity that the new mask isn't
> visible via cat /proc/irq/M/smp_affinity until after actual interrupts
> are taken?
Intel chipsets can only safely update affinity during interrupt processing.
You see a side effect of the code implementing this restriction.
-Andi
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: smp_affinity, MSI-X and 2.6.21.1
2007-05-09 9:46 ` David Miller
@ 2007-05-09 11:50 ` Andi Kleen
2007-05-15 22:52 ` Rick Jones
0 siblings, 1 reply; 7+ messages in thread
From: Andi Kleen @ 2007-05-09 11:50 UTC (permalink / raw)
To: David Miller; +Cc: andi, rick.jones2, netdev, tglx, mingo
> That's true, but we are talking about software state so in some sense
> it might be better that the affinity-to-be is reported to the user in
> this case.
>
> Delayed register updates are an implementation detail the user does
> not need to know about here.
This patch should fix it.
-Andi
Report the pending irq if available in smp_affinity
Otherwise smp_affinity would only update after the next interrupt
on x86 systems.
Cc: tglx@linutronix.de
Cc: mingo@elte.hu
Signed-off-by: Andi Kleen <ak@suse.de>
Index: linux/kernel/irq/proc.c
===================================================================
--- linux.orig/kernel/irq/proc.c
+++ linux/kernel/irq/proc.c
@@ -19,7 +19,14 @@ static struct proc_dir_entry *root_irq_d
static int irq_affinity_read_proc(char *page, char **start, off_t off,
int count, int *eof, void *data)
{
- int len = cpumask_scnprintf(page, count, irq_desc[(long)data].affinity);
+ struct irq_desc *desc = irq_desc + (long)data;
+ cpumask_t *mask = &desc->affinity;
+ int len;
+#ifdef CONFIG_GENERIC_PENDING_IRQ
+ if (desc->status & IRQ_MOVE_PENDING)
+ mask = &desc->pending_mask;
+#endif
+ len = cpumask_scnprintf(page, count, *mask);
if (count - len < 2)
return -EINVAL;
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: smp_affinity, MSI-X and 2.6.21.1
2007-05-09 11:50 ` Andi Kleen
@ 2007-05-15 22:52 ` Rick Jones
0 siblings, 0 replies; 7+ messages in thread
From: Rick Jones @ 2007-05-15 22:52 UTC (permalink / raw)
To: Andi Kleen; +Cc: David Miller, netdev, tglx, mingo
Andi Kleen wrote:
>>That's true, but we are talking about software state so in some sense
>>it might be better that the affinity-to-be is reported to the user in
>>this case.
>>
>>Delayed register updates are an implementation detail the user does
>>not need to know about here.
>
>
> This patch should fix it.
And it seems to when I apply it against the 2.6.21.1 kernel I'm messing about with:
hpcpc106:~/s2io-2.0.19-8893# cat /proc/irq/69/smp_affinity
ffffffff,ffffffff
hpcpc106:~/s2io-2.0.19-8893# echo "4" >> /proc/irq/69/smp_affinity
hpcpc106:~/s2io-2.0.19-8893# cat /proc/irq/69/smp_affinity
00000000,00000004
hpcpc106:~/s2io-2.0.19-8893# cat /proc/interrupts | grep 69
69: 0 0 0 0 PCI-MSI eth2:MSI-X-6-RX
It would be nice if this could find its way into the kernel at some point -
2.6.23 or 2.6.24 perhaps?
rick jones
> -Andi
>
> Report the pending irq if available in smp_affinity
>
> Otherwise smp_affinity would only update after the next interrupt
> on x86 systems.
>
> Cc: tglx@linutronix.de
> Cc: mingo@elte.hu
>
> Signed-off-by: Andi Kleen <ak@suse.de>
>
> Index: linux/kernel/irq/proc.c
> ===================================================================
> --- linux.orig/kernel/irq/proc.c
> +++ linux/kernel/irq/proc.c
> @@ -19,7 +19,14 @@ static struct proc_dir_entry *root_irq_d
> static int irq_affinity_read_proc(char *page, char **start, off_t off,
> int count, int *eof, void *data)
> {
> - int len = cpumask_scnprintf(page, count, irq_desc[(long)data].affinity);
> + struct irq_desc *desc = irq_desc + (long)data;
> + cpumask_t *mask = &desc->affinity;
> + int len;
> +#ifdef CONFIG_GENERIC_PENDING_IRQ
> + if (desc->status & IRQ_MOVE_PENDING)
> + mask = &desc->pending_mask;
> +#endif
> + len = cpumask_scnprintf(page, count, *mask);
>
> if (count - len < 2)
> return -EINVAL;
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-05-15 22:52 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-05-07 20:53 smp_affinity, MSI-X and 2.6.21.1 Rick Jones
2007-05-07 23:07 ` Arjan van de Ven
2007-05-08 0:09 ` Rick Jones
2007-05-09 10:35 ` Andi Kleen
2007-05-09 9:46 ` David Miller
2007-05-09 11:50 ` Andi Kleen
2007-05-15 22:52 ` Rick Jones
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.