* 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-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 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-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.