linux-kernel - Re: High-priority softirqs [was: [PATCH] usb: don't offload isochronous urb completions to ksoftirq]

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: <alpine.LRH.2.02.1806151658000.24974@file01.intranet.prod.int.rdu2.redhat.com>
Date:   Fri, 15 Jun 2018 17:05:01 -0400 (EDT)
From:   Mikulas Patocka <mpatocka@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>
cc:     Alan Stern <stern@...land.harvard.edu>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ming Lei <ming.lei@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        USB list <linux-usb@...r.kernel.org>,
        Kernel development list <linux-kernel@...r.kernel.org>,
        Sebastian Sewior <bigeasy@...utronix.de>
Subject: Re: High-priority softirqs [was: [PATCH] usb: don't offload isochronous
 urb completions to ksoftirq]

On Fri, 15 Jun 2018, Thomas Gleixner wrote:

> One solution to that is to avoid both tasklets and kworkers and change the
> USB code to make use of threaded interrupt handlers. I.e. handle the fast
> stuff in the primary (hardirq) handler and delegate the rest to the irq
> thread. That thread still can offload disk type stuff to a kworker if
> needed. But the irq thread allows to bring the stuff under scheduler
> control and experiments which I did a few years ago worked out pretty good.
> 
> Thanks,
> 
> 	tglx

I don't think that threaded interrupt handlers are a good idea.

There are existing tools such as rtkit in Linux distributions that 
increase the priority of audio applications to real time. And if rtkit 
increases the priority of audio player or audio server above the priority 
of the interrupt thread that handles the soundcard - sound playback is 
screwed.

You would have to set the priority of the interrupt thread to the highest 
real-time priority - and in such a case, the interrupt thread is no 
different than a hard-irq handler.

Mikulas