[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c0f779f1d5ef131c39f9397f97d453e8@mail.gmail.com>
Date: Wed, 5 Sep 2018 15:15:20 +0530
From: Kashyap Desai <kashyap.desai@...adcom.com>
To: Dou Liyang <dou_liyang@....com>,
Thomas Gleixner <tglx@...utronix.de>
Cc: Ming Lei <tom.leiming@...il.com>,
Sumit Saxena <sumit.saxena@...adcom.com>,
Ming Lei <ming.lei@...hat.com>, Christoph Hellwig <hch@....de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Shivasharan Srikanteshwara
<shivasharan.srikanteshwara@...adcom.com>,
linux-block <linux-block@...r.kernel.org>,
Dou Liyang <douly.fnst@...fujitsu.com>
Subject: RE: Affinity managed interrupts vs non-managed interrupts
> Hi Thomas, Kashyap,
>
> At 09/04/2018 06:29 PM, Kashyap Desai wrote:
> >>> I am using " for-4.19/block " and this particular patch "a0c9259
> >>> irq/matrix: Spread interrupts on allocation" is included.
> >>
>
> IMO, this patch is just used for non-managed interrupts.
>
> >> So if all 16 have their effective affinity set to CPU0 then that's
> > strange
>
> But, all these 16 are managed interrupts, and will be assigned vectors
> by assign_managed_vector():
> {
> cpumask_and(vector_searchmask, vector_searchmask, affmsk);
> cpu = cpumask_first(vector_searchmask);
>
> ...
> vector = irq_matrix_alloc_managed(vector_matrix, cpu);
> ...
> }
>
> Where we always used the *first* cpu in the vector_searchmask(0-71), not
> the suitable one. So I guess this situation happened.
>
> Shall we also spread the managed interrupts on allocation?
Hi Dou,
I tried your proposed patch. Using patch, It is not assigning effective irq
to CPU = 0 , but it pick *one* cpu from 0-71 range.
Eventually, effective cpu is always *one* logical cpu. Behavior is
different, but impact is still same.
Powered by blists - more mailing lists