linux-kernel - Re: [RFC PATCH 0/2] RT scheduling policies for workqueues

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: <YkGIhYKJG+w4L7ge@linutronix.de>
Date:   Mon, 28 Mar 2022 12:05:57 +0200
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Tejun Heo <tj@...nel.org>, Lai Jiangshan <jiangshanlai@...il.com>,
        linux-kernel@...r.kernel.org,
        André Pribil <a.pribil@...k-ipc.com>,
        Steven Walter <stevenrwalter@...il.com>,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        Esben Haabendal <esben@...nix.com>,
        Jiri Slaby <jirislaby@...nel.org>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Peter Hurley <peter@...leysoftware.com>,
        linux-rt-users@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] RT scheduling policies for workqueues

On 2022-03-23 15:55:58 [+0100], Rasmus Villemoes wrote:
> This RFC is motivated by an old problem in the tty layer. Ever since
> commit a9c3f68f3cd8 (tty: Fix low_latency BUG), use of UART for
> real-time applications has been problematic. Even if both the
> application itself and the irq thread are set to SCHED_FIFO, the fact
> that the flush_to_ldisc work is scheduled on the generic and global
> system_unbound_wq (with all workers running at normal scheduling
> priority) means that UART RX can suffer unbounded latency.

Having a kthread per "low-latency" tty instance is something I would
prefer. The kwork corner is an anonymous worker instance and probably
does more harm than good. Especially if it is a knob for everyone which
is used for the wrong reasons and manages to be harmful in the end.
With a special kthread for a particular tty, the thread can be assigned
with the desired priority within the system and ttyS1 can be
distinguished from ttyS0 (and so on). This turned out to be useful in a
few setups over the years.

Sebastian