linux-kernel - Re: [RFC/PATCHv2] kernel/irq: allow more precise irq affinity policies

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 26 Sep 2010 20:57:51 -0700
From:	Arthur Kepner <akepner@....com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	linux-kernel@...r.kernel.org,
	Ben Hutchings <bhutchings@...arflare.com>
Subject: Re: [RFC/PATCHv2] kernel/irq: allow more precise irq affinity
	policies

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/