From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: "Tejun Heo" <tj@kernel.org>,
"Lai Jiangshan" <jiangshanlai@gmail.com>,
linux-kernel@vger.kernel.org,
"André Pribil" <a.pribil@beck-ipc.com>,
"Steven Walter" <stevenrwalter@gmail.com>,
"Oleksij Rempel" <o.rempel@pengutronix.de>,
"Esben Haabendal" <esben@geanix.com>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Pengutronix Kernel Team" <kernel@pengutronix.de>,
"Peter Hurley" <peter@hurleysoftware.com>,
linux-rt-users@vger.kernel.org
Subject: Re: [RFC PATCH 0/2] RT scheduling policies for workqueues
Date: Mon, 28 Mar 2022 12:05:57 +0200 [thread overview]
Message-ID: <YkGIhYKJG+w4L7ge@linutronix.de> (raw)
In-Reply-To: <20220323145600.2156689-1-linux@rasmusvillemoes.dk>
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
next prev parent reply other threads:[~2022-03-28 10:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-23 14:55 [RFC PATCH 0/2] RT scheduling policies for workqueues Rasmus Villemoes
2022-03-23 14:55 ` [RFC PATCH 1/2] workqueue: allow use of realtime scheduling policies Rasmus Villemoes
2022-03-23 14:56 ` [RFC PATCH 2/2] workqueue: update sysfs handlers, allow setting RT policies Rasmus Villemoes
2022-03-28 10:05 ` Sebastian Andrzej Siewior [this message]
2022-03-28 10:09 ` [RFC PATCH 0/2] RT scheduling policies for workqueues Marc Kleine-Budde
2022-03-28 17:39 ` Tejun Heo
2022-03-28 18:07 ` Marc Kleine-Budde
2022-03-29 6:30 ` Sebastian Andrzej Siewior
2022-03-29 8:33 ` Rasmus Villemoes
2022-03-29 16:57 ` Tejun Heo
2022-04-01 9:21 ` Sebastian Andrzej Siewior
2022-04-06 10:00 ` Rasmus Villemoes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YkGIhYKJG+w4L7ge@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=a.pribil@beck-ipc.com \
--cc=esben@geanix.com \
--cc=jiangshanlai@gmail.com \
--cc=jirislaby@kernel.org \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=o.rempel@pengutronix.de \
--cc=peter@hurleysoftware.com \
--cc=stevenrwalter@gmail.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox