Messages in this thread | | | Date | Wed, 6 Dec 2017 16:31:13 +0100 | From | Greg KH <> | Subject | Re: [PATCH] uio: Allow to take irq bottom-half into irq_handler with additional dt-binding |
| |
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 <andrey.z@gmail.com>
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
| |