From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2FA5B352924 for ; Fri, 5 Dec 2025 17:47:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764956862; cv=none; b=tJOufY0gVTR6usOaNLyusE35FdFsS55CWKJxmk6p6577d07LkgzodHz+Tbktt9sLfYQDIkyDEWLp/uJlHqkKOyrXlQ2CTGzRSiEI2vBXUzMAgDsSCb/jrln0UgnLvM4dDJIpnNPGtSQDW11mn1uhZos851nTlzjZgR27kJ45J/c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764956862; c=relaxed/simple; bh=+rxJjSQMB15OBWZB5KZ5VSa8izkTXONc5RE5KizCnpM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SvFt0VJRuCpcBmmrKnOmqbYvT4V7V6e2iCU3L5U+fbYcRWwNJPkmug5SDL/yLvVyreenrEtgEgvMGl4IwpvOSX4qrzY6Ox8Mj6tUPeK6nEqttGdSm/F597cHI4IaC8QTqGjgxj7A5RPrPjVVoIg9nQwhfyO9wTggtV0r64E8mIY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=otIoRVnI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="otIoRVnI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12043C4CEF1; Fri, 5 Dec 2025 17:47:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764956861; bh=+rxJjSQMB15OBWZB5KZ5VSa8izkTXONc5RE5KizCnpM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=otIoRVnIv4sTLvzNu3dhU/Pmjk3ZmtQFzFG1xylyDrZ+B1tjfee4w4eTDxBcZWRAb jIY8j2S9RJCVdzrwUxFQD3qw2hhTSxxeaFcT4bm0V8sq24VRoeHwhJml3meSMd7bnH 297mWYwynW3xDETffEUQXjj56m3dCZpHTEcBo5NfHgjvrGGSgxGPjjk6QGLxlR6nZZ 4qpDgkrVUwvloUsquE5uZk8489BUBOw1EJtw6J2iV2pPg2OuejwAzk8IcdChKXVGZl BF2TnLNdshZ4nwrRJPiQZebk4ECOFuspRvXHx6t6f59aqFOJH18/40Mm8WcmlLna5b L0A3xMJlrCPMA== Date: Fri, 5 Dec 2025 07:47:40 -1000 From: Tejun Heo To: Xin Zhao Cc: jiangshanlai@gmail.com, hch@infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/3] workqueue: Add configure to reduce work latency Message-ID: References: <20251205125445.4154667-1-jackzxcui1989@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251205125445.4154667-1-jackzxcui1989@163.com> Hello, On Fri, Dec 05, 2025 at 08:54:42PM +0800, Xin Zhao wrote: > In a system with high real-time requirements, we have noticed that many > high-priority tasks, such as kernel threads responsible for dispatching > GPU tasks and receiving data sources, often experience latency spikes > due to insufficient real-time execution of work. > The existing sysfs can adjust nice value for unbound workqueues. Add new > 'policy' node to support three common policies: SCHED_NORMAL, SCHED_FIFO, > or SCHED_RR. The original 'nice' node is retained for compatibility, add > new 'rtprio' node to adjust real-time priority when 'policy' is SCHED_FIFO > or SCHED_RR. The value of 'rtprio' uses the same numerical meaning as user > space tool chrt. > Introduce variable 'nr_idle_extra', which allows user space to configure > unbound workqueue through sysfs according to the real-time requirement. > By default, workqueue created by system will set 'nr_idle_extra' to 0. > When the policy of workqueue is set to SCHED_FIFO or SCHED_RR via sysfs, > 'nr_idle_extra' will be set to WORKER_NR_RT_DEF(2) as default. > Supporting the private configuration aims to deterministically ensure that > tasks within one workqueue are not affected by tasks from other workqueues > with the same attributes. If the user has high real-time requirements, > they can increase the nr_idle_extra supported in the previous patch while > also setting the workqueue 'private', allowing it to independently use > kworker threads, thus ensuring scheduling-related work delays never occur. I don't think I'm applying this: - The rationale is too vague. What are you exactly running and observing? How does this improve the situation? - If wq supports private pools, then I don't think it makes sense to add wq interface to change their attributes. Once turned private, the worker threads are fixed and userspace can set whatever attributes they want to set, no? Thanks. -- tejun