linux-kernel - Re: [PATCH 02/13] genirq/affinity: Provide smarter irq spreading infrastructure

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1609222309300.5640@nanos>
Date:   Thu, 22 Sep 2016 23:14:30 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Alexander Gordeev <agordeev@...hat.com>
cc:     Christoph Hellwig <hch@....de>, axboe@...com,
        keith.busch@...el.com, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/13] genirq/affinity: Provide smarter irq spreading
 infrastructure

Alexander,

On Wed, 21 Sep 2016, Alexander Gordeev wrote:
> On Wed, Sep 14, 2016 at 04:18:48PM +0200, Christoph Hellwig wrote:
> > +/**
> > + * irq_calc_affinity_vectors - Calculate to optimal number of vectors for a given affinity mask
> > + * @affinity:		The affinity mask to spread. If NULL cpu_online_mask
> > + *			is used
> > + * @maxvec:		The maximum number of vectors available
> > + */
> > +int irq_calc_affinity_vectors(const struct cpumask *affinity, int maxvec)
> > +{
> > +	int cpus, ret;
> > +
> > +	/* Stabilize the cpumasks */
> > +	get_online_cpus();
> > +	/* If the supplied affinity mask is NULL, use cpu online mask */
> > +	if (!affinity)
> > +		affinity = cpu_online_mask;
> > +
> > +	cpus = cpumask_weight(affinity);
> 
> Should not we consider the result of AND of affinity and cpu_online_mask?

That's a good question.

The argument against it is the increased usage of cpu (soft)hotplug for
power-management. The driver might well want to set the mapping even for an
offline cpu and as long as the interrupt is not requested for that
particular queue, it will stay (in software) associated to that cpu. So
once the CPU is brought up again the driver can request the interrupt and
work with the associated queue.

I'm aware that there are arguments against it, but lets see how it works
out.

Thanks,

	tglx