The function __irq_set_affinity is referenced by interrupt.h
with static inlines, but if you try to use one of the inlines
in interrupt.h (for instance to call irq_set_affinity) then
compile fails due to a missing symbol, when building modules.
Enabling this function means that kernel drivers can include
an initial affinity setting for the interrupt, instead of all
interrupts starting out life on CPU0. It seems to have just
been an oversight that it was not included.
This function and the helpers that call it from interrupt.h were
already in the kernel API, but if used would then fail to compile
due to the lack of an export even though already defined via extern.
Signed-off-by: Jesse Brandeburg <[email protected]>
CC: Thomas Gleixner <[email protected]>
---
Note: The use of EXPORT_SYMBOL_GPL was only because the next
latest function added to this file (irq_set_affinity_hint)
also used it.
---
kernel/irq/manage.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 8069237..8c1a5ad 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -233,6 +233,7 @@ int __irq_set_affinity(unsigned int irq, const struct cpumask *mask, bool force)
raw_spin_unlock_irqrestore(&desc->lock, flags);
return ret;
}
+EXPORT_SYMBOL_GPL(__irq_set_affinity);
int irq_set_affinity_hint(unsigned int irq, const struct cpumask *m)
{
On Thu, 18 Dec 2014, Jesse Brandeburg wrote:
> The function __irq_set_affinity is referenced by interrupt.h
> with static inlines, but if you try to use one of the inlines
> in interrupt.h (for instance to call irq_set_affinity) then
> compile fails due to a missing symbol, when building modules.
>
> Enabling this function means that kernel drivers can include
> an initial affinity setting for the interrupt, instead of all
> interrupts starting out life on CPU0. It seems to have just
> been an oversight that it was not included.
>
> This function and the helpers that call it from interrupt.h were
> already in the kernel API, but if used would then fail to compile
> due to the lack of an export even though already defined via extern.
And why needs this to be called from modules? Just because or is there
a legitimate reason? IOW, you forgot to describe the actual usecase.
Thanks,
tglx
On Thu, 18 Dec 2014 23:42:03 +0100
Thomas Gleixner <[email protected]> wrote:
> On Thu, 18 Dec 2014, Jesse Brandeburg wrote:
> > Enabling this function means that kernel drivers can include
> > an initial affinity setting for the interrupt, instead of all
> > interrupts starting out life on CPU0. It seems to have just
> > been an oversight that it was not included.
> And why needs this to be called from modules? Just because or is there
> a legitimate reason? IOW, you forgot to describe the actual usecase.
As stated above, the use case for my interest is making a network
driver's many interrupt vectors not all show up on CPU0. Of course a
user can work around this by manually tuning smp_affinity, but I have
seen many reports from users and testers where the performance of the
network was really bad due to all network interrupts on CPU0.
This allows the driver to set a sane default smp_affinity value at
driver load.
Would you instead consider a patch where if a user calls the
set_irq_affinity_hint that the initial affinity is set to the hinted
value?
On Thu, 18 Dec 2014, Jesse Brandeburg wrote:
> On Thu, 18 Dec 2014 23:42:03 +0100
> Thomas Gleixner <[email protected]> wrote:
>
> > On Thu, 18 Dec 2014, Jesse Brandeburg wrote:
> > > Enabling this function means that kernel drivers can include
> > > an initial affinity setting for the interrupt, instead of all
> > > interrupts starting out life on CPU0. It seems to have just
> > > been an oversight that it was not included.
>
> > And why needs this to be called from modules? Just because or is there
> > a legitimate reason? IOW, you forgot to describe the actual usecase.
>
> As stated above, the use case for my interest is making a network
> driver's many interrupt vectors not all show up on CPU0. Of course a
> user can work around this by manually tuning smp_affinity, but I have
> seen many reports from users and testers where the performance of the
> network was really bad due to all network interrupts on CPU0.
>
> This allows the driver to set a sane default smp_affinity value at
> driver load.
Fair enough. Overloaded brain missed parts of the explanation. :)
> Would you instead consider a patch where if a user calls the
> set_irq_affinity_hint that the initial affinity is set to the hinted
> value?
That would make a lot of sense, because you probably will set the
affinity hint anyway, right?
Thanks,
tglx