Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753969AbcDAIak (ORCPT ); Fri, 1 Apr 2016 04:30:40 -0400 Received: from foss.arm.com ([217.140.101.70]:59263 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752055AbcDAIag (ORCPT ); Fri, 1 Apr 2016 04:30:36 -0400 Subject: Re: [RFC PATCH] genirq: Change the non-balanced irq to balance irq when the cpu of the irq bounded off line To: MaJun , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, tglx@linutronix.de, lizefan@huawei.com, huxinwei@huawei.com, dingtianhong@huawei.com, guohanjun@huawei.com, wuyun.wu@huawei.com, yangyingliang@huawei.com References: <1459481291-10136-1-git-send-email-majun258@huawei.com> From: Marc Zyngier X-Enigmail-Draft-Status: N1110 Organization: ARM Ltd Message-ID: <56FE31A8.1020502@arm.com> Date: Fri, 1 Apr 2016 09:30:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <1459481291-10136-1-git-send-email-majun258@huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1543 Lines: 40 Hi Ma Jun, On 01/04/16 04:28, MaJun wrote: > From: Ma Jun > > When the CPU of a non-balanced irq bounded is off line, the irq will be migrated to other CPUs, > usually the first cpu on-line. > > We can suppose the situation if a system has more than one non-balanced irq. > At extreme case, these irqs will be migrated to the same CPU and will cause the > CPU run with high irq pressure, even make the system die. It would take a hell of lot of interrupts (and a very badly designed system) for that system to collapse under the interrupt load. Whatever people tend to think, interrupts are a very rare event. Any moderately ancient CPU can take several hundred of thousand interrupts per second, and you still barely notice it (try any embedded platform with a bunch of MMC controllers...). Now, let's get to the actual question: > So, I think maybe we need to change the non-balanced irq to a irq can be > balanced to avoid the problem descried above. But what makes you think that you can safely clear that flag? If it has been excluding from balancing, that's surely for a good reason, and the device driver that requested this probably doesn't expect the interrupt affinity to change, other than by the effect of CPU hotplug itself. So if you're seeing a problem with an interrupt not being balanced, please first investigate *why* the driver asked for it the first place. But to the best of my understanding, this patch doesn't solve anything. Thanks, N, -- Jazz is not dead. It just smells funny...