Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752286AbcJIT0e (ORCPT ); Sun, 9 Oct 2016 15:26:34 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:47970 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752168AbcJIT0c (ORCPT ); Sun, 9 Oct 2016 15:26:32 -0400 Date: Sun, 9 Oct 2016 21:23:58 +0200 (CEST) From: Thomas Gleixner To: Rich Felker cc: linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org, Jason Cooper , Marc Zyngier , Daniel Lezcano , "Paul E. McKenney" Subject: Re: [PATCH] irqchip/jcore: fix lost per-cpu interrupts In-Reply-To: <20161009144715.GB19318@brightrain.aerifal.cx> Message-ID: References: <41fc74d0bdea4c0efc269150b78d72b2b26cb38c.1475992312.git.dalias@libc.org> <20161009144715.GB19318@brightrain.aerifal.cx> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1348 Lines: 31 On Sun, 9 Oct 2016, Rich Felker wrote: > On Sun, Oct 09, 2016 at 01:03:10PM +0200, Thomas Gleixner wrote: > My preference would just be to keep the branch, but with your improved > version that doesn't need a function call: > > irqd_is_per_cpu(irq_desc_get_irq_data(desc)) > > While there is some overhead testing this condition every time, I can > probably come up with several better places to look for a ~10 cycle > improvement in the irq code path without imposing new requirements on > the DT bindings. Fair enough. Your call. > As noted in my followup to the clocksource stall thread, there's also > a possibility that it might make sense to consider the current > behavior of having non-percpu irqs bound to a particular cpu as part > of what's required by the compatible tag, in which case > handle_percpu_irq or something similar/equivalent might be suitable > for both the percpu and non-percpu cases. I don't understand the irq > subsystem well enough to insist on that but I think it's worth > consideration since it looks like it would improve performance of > non-percpu interrupts a bit. Well, you can use handle_percpu_irq() for your device interrupts if you guarantee at the hardware level that there is no reentrancy. Once you make the hardware capable of delivering them on either core the picture changes. Thanks, tglx