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: <580116EB.7050106@arm.com>
Date:   Fri, 14 Oct 2016 18:33:31 +0100
From:   Marc Zyngier <marc.zyngier@....com>
To:     Cheng Chao <cs.os.kernel@...il.com>
Cc:     tglx@...utronix.de, jason@...edaemon.net,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] irqchip/gic: Enable gic_set_affinity set more than one
 cpu

On 14/10/16 03:08, Cheng Chao wrote:
> Marc,
> 
>   Thanks for your comments.
> 
> Cheng
> 
> on 10/13/2016 11:31 PM, Marc Zyngier wrote:
>> On Thu, 13 Oct 2016 18:57:14 +0800
>> Cheng Chao <cs.os.kernel@...il.com> wrote:
>>
>>> GIC can distribute an interrupt to more than one cpu,
>>> but now, gic_set_affinity sets only one cpu to handle interrupt.
>>
>> What makes you think this is a good idea? What purpose does it serves?
>> I can only see drawbacks to this: You're waking up more than one CPU,
>> wasting power, adding jitter and clobbering the cache.
>>
>> I assume you see a benefit to that approach, so can you please spell it
>> out?
>>
> 
> Ok, You are right, but the performance is another point that we should consider. 
> 
> We use E1 device to transmit/receive video stream. we find that E1's interrupt is
> only on the one cpu that cause this cpu usage is almost 100%, 
> but other cpus is much lower load, so the performance is not good.
> the cpu is 4-core.

It looks to me like you're barking up the wrong tree. We have
NAPI-enabled network drivers for this exact reason, and adding more
interrupts to an already overloaded system doesn't strike me as going in
the right direction. May I suggest that you look at integrating NAPI
into your E1 driver?

> so add CONFIG_ARM_GIC_AFFINITY_SINGLE_CPU is better?
> thus we can make a trade-off between the performance with the power etc.

No, that's pretty horrible, and I'm not even going to entertain the
idea. I suggest you start investigating how to mitigate your interrupt
rate instead of just taking more of them.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ