From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752545AbdLFPbJ (ORCPT ); Wed, 6 Dec 2017 10:31:09 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:52668 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751444AbdLFPbH (ORCPT ); Wed, 6 Dec 2017 10:31:07 -0500 Date: Wed, 6 Dec 2017 16:31:13 +0100 From: Greg KH To: Andrey Zhizhikin Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] uio: Allow to take irq bottom-half into irq_handler with additional dt-binding Message-ID: <20171206153113.GB29623@kroah.com> References: <1512572140-48009-1-git-send-email-andrey.z@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1512572140-48009-1-git-send-email-andrey.z@gmail.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 06, 2017 at 03:55:40PM +0100, Andrey Zhizhikin wrote: > Certain Kernel preemption models are using threaded interrupt handlers, > which is in general quite beneficial. However, threaded handlers > introducing additional scheduler overhead, when the bottom-half thread > should be woken up and scheduled for execution. This can result is > additional latency, which in certain cases is not desired. > > UIO driver with Generic IRQ handler, that wraps a HW block might suffer > a small degradation when it's bottom half is executed, since it needs > its bottom half to be woken up by the scheduler every time INT is > delivered. For high rate INT signals, this also bring additional > undesired load on the scheduler itself. > > Since the actual ACK is performed in the top-half, and bottom-half of > the UIO driver with Generic IRQ handler is relatively slick (only flag > is set based on the INT reception), it might be beneficial to move this > bottom-half to the irq_handler itself, rather than to have a separate > thread to service it. > > This patch aims to address the task above, and in addition introduces > a new dt-binding which could be configured on a per-node basis. That > means developers utilizing the UIO driver could decide which UIO > instance is critical in terms of interrupt processing, and move their > corresponding bottom-halves to the irq_handler to fight additional > scheduling latency. > > New DT binding: > - no-threaded-irq: when present, request_irq() is called with > IRQF_NO_THREAD flag set, effectively skipping threaded interrupt > handler and taking bottom-half into irq_handler > > Signed-off-by: Andrey Zhizhikin For new DT bindings, don't you have to add them to the in-kernel documentation and get an ack from the DT maintainers? Please do that here. ALso, how much does this really save in latency/delay by not allowing a threaded irq? What about systems that run all irqs in threaded mode? Will that break something here? thanks, greg k-h