Re: [RFC/PATCHv2] kernel/irq: allow more precise irq affinitypolicies

[Arthur Kepner]

On Thu, Sep 23, 2010 at 08:36:35PM +0200, Thomas Gleixner wrote:
> 
> I thought more about this and came to the conclusion that this
> facility is completely overengineered and mostly useless except for a
> little detail.
> 
> The only problem which it solves is to prevent that we run out of
> vectors on the low numbered cpus when that NIC which insists to create
> one irq per cpu starts up.

Yep, that's the problem.

> 
> Fine, I can see that this is a problem, but we do not need this
> complete nightmare to solve it. We can do that way simpler.
> 
>  1) There is a patch from your coworker to work around that in the low
>     level x86 code, which is probably working, but suboptimal and not
>     generic
>

I don't know what you're referring to there.
 
>  2) We already know that the NIC requested the irq on node N. So when
>     we set it up, we just honour the wish of the driver as long as it
>     fits in the default (or modified) affinity mask and restrict the
>     affinity to the cpus on that very node.
> 
>     That makes a whole lot of sense: The driver already knows on which
>     cpus it wants to see the irq, because it allocated queues and
>     stuff there.
> 
>     So that's probably a 10 lines or less patch do fix that.
> ....

OK, the simple approach is fine with me. I'll send a patch in 
a minute.

-- 
Arthur
--
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/