Re: [PATCH 2/2] irq: only update affinity in chip set_affinity()
From: Ingo Molnar
Date: Wed Apr 08 2009 - 11:59:38 EST
* Yinghai Lu <yhlu.kernel@xxxxxxxxx> wrote:
> On Wed, Apr 8, 2009 at 5:54 AM, Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> > * Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
> >
> >> Impact: keep affinity consistent
> >>
> >> irq_set_affinity() and move_masked_irq() try to assign affinity
> >> before calling chip set_affinity(). some archs are assigning again
> >> in set_affinity again.
> >>
> >> something like:
> >> cpumask_cpy(desc->affinity, mask);
> >> desc->chip->set_affinity(mask);
> >>
> >> in the failing path, affinity should not be touched.
> >>
> >> also set_extra_move_desc() ( called by set_affinity) will rely on
> >> the old affinity to decide if need to move irq_desc to different
> >> node when logical flat apic mode is used.
> >>
> >> So try remove those assignment, and make some missed arch to
> >> assign affinity in their set_affinity.
> >>
> >> Signed-off-by: Yinghai Lu <yinghai@xxxxxxxxxx>
> >>
> >> --
> >> arch/alpha/kernel/sys_dp264.c | 6 ++++--
> >> arch/alpha/kernel/sys_titan.c | 3 ++-
> >> arch/arm/common/gic.c | 1 +
> >> arch/cris/arch-v32/kernel/irq.c | 1 +
> >> arch/ia64/kernel/iosapic.c | 3 +++
> >> arch/ia64/sn/kernel/irq.c | 3 +++
> >> arch/mips/cavium-octeon/octeon-irq.c | 6 ++++++
> >> arch/mips/sibyte/bcm1480/irq.c | 2 ++
> >> arch/mips/sibyte/sb1250/irq.c | 2 ++
> >> arch/powerpc/platforms/pseries/xics.c | 5 +++++
> >> arch/powerpc/sysdev/mpic.c | 2 ++
> >> arch/sparc/kernel/irq_64.c | 7 +++++++
> >> drivers/xen/events.c | 2 ++
> >> kernel/irq/manage.c | 6 ++----
> >> kernel/irq/migration.c | 8 +++-----
> >> 15 files changed, 45 insertions(+), 12 deletions(-)
> >
> > Hm, this spreads a lot of instances of identical lines:
> >
> > cpumask_copy(irq_desc[irq].affinity, mask_val);
> >
> > all around architectures. How is that an improvement?
> >
>
> in failing path in set_affinity, for example it can not get vector
> in specified cpu, then affinity should not be changed.
isnt the right solution then to propagate the failure code back to
the generic code?
Preferably via a new callback, and the patches only touching the
core code plus maybe x86, so that other architectures can be
converted/fixed more gradually.
Ingo
--
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/