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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ