From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4A06C433FE for ; Mon, 28 Mar 2022 10:06:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240158AbiC1KHs (ORCPT ); Mon, 28 Mar 2022 06:07:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236973AbiC1KHp (ORCPT ); Mon, 28 Mar 2022 06:07:45 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 364FB53B7D; Mon, 28 Mar 2022 03:06:01 -0700 (PDT) Date: Mon, 28 Mar 2022 12:05:57 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1648461959; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nRISlRawsY/q0M9hXgY2Ak8V5Zf/qjZAd7pD8o0Pf34=; b=imraXrXwOIBRUqeX6f4kk2VW1BI7XdqTLWCh6CLQW6V6CMVM+9hBlrJ6DAYIkH71rWav0G IXRIU6OOw4S+LiTdD1RX1Wpy4EuK71bfrWNFiio9somxxHA2t3rJLH/WunI0ABbCvGlJwL d5umqSHYiqiX2cbry8XKb3qdw5DeaO1kyuEEC1z05ZKakIqZCrBAvRPWvRkRrb/mlB9LX6 bSl1EbwKkPg4zJ2PPqN8xZYR4UVCyVXElopdq58lH1Lx3O1xUoByh7rXo3ZtCR5VG2RUHO J2YvPKpR0HWLDF2XirO671N350oKFrdxWVc4KEi+EVwDYo5ZYoXpUxH348JToA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1648461959; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nRISlRawsY/q0M9hXgY2Ak8V5Zf/qjZAd7pD8o0Pf34=; b=IQl8AKJE/iMGjFgEy+MFcySwLY3ow/EFjnR3gfWJlXKvwT6lD82wvA+TcjjcQbcqG+nJs0 0ePcw/0eObqTTzBg== From: Sebastian Andrzej Siewior To: Rasmus Villemoes Cc: Tejun Heo , Lai Jiangshan , linux-kernel@vger.kernel.org, =?utf-8?B?QW5kcsOp?= Pribil , Steven Walter , Oleksij Rempel , Esben Haabendal , Jiri Slaby , Pengutronix Kernel Team , Peter Hurley , linux-rt-users@vger.kernel.org Subject: Re: [RFC PATCH 0/2] RT scheduling policies for workqueues Message-ID: References: <20220323145600.2156689-1-linux@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220323145600.2156689-1-linux@rasmusvillemoes.dk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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