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 96CE5C04A6A for ; Thu, 3 Aug 2023 20:20:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230081AbjHCUTU (ORCPT ); Thu, 3 Aug 2023 16:19:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46598 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229500AbjHCUTS (ORCPT ); Thu, 3 Aug 2023 16:19:18 -0400 Received: from p3plsmtpa09-02.prod.phx3.secureserver.net (p3plsmtpa09-02.prod.phx3.secureserver.net [173.201.193.231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 953B53C31 for ; Thu, 3 Aug 2023 13:19:16 -0700 (PDT) Received: from localhost ([82.27.99.45]) by :SMTPAUTH: with ESMTPA id RemwqV4JViMnJRemxqtkdH; Thu, 03 Aug 2023 13:19:16 -0700 X-CMAE-Analysis: v=2.4 cv=I62jBvsg c=1 sm=1 tr=0 ts=64cc0bc4 a=YwMIiW7BGddQzL8MrqPWMg==:117 a=YwMIiW7BGddQzL8MrqPWMg==:17 a=ENF2c8OQyt5_Ph5qRQ4A:9 a=zgiPjhLxNE0A:10 X-SECURESERVER-ACCT: atomlin@atomlin.com From: Aaron Tomlin To: tj@kernel.org Cc: atomlin@atomlin.com, jiangshanlai@gmail.com, linux-kernel@vger.kernel.org, peterz@infradead.org Subject: Re: [RFC PATCH 0/2] workqueue: Introduce PF_WQ_RESCUE_WORKER Date: Thu, 3 Aug 2023 21:19:14 +0100 Message-Id: <20230803201914.1802437-1-atomlin@atomlin.com> X-Mailer: git-send-email 2.39.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfO/evbuumYY5KOSMgpzYfQ9L3GiEoM5+QS6fd9qOFWeU8XlN11HChkpFukyiHakzyML2YCCfLRl8SF+TsWHgTVrzDszPvAkwIR2nyyABljlnyx2OGTbD 8BOyiRSu8Wyl5ec/8Mm9riMehyFYwJX7LtMkIcpjQdUfI1l612NIWyDSNzepVdZ0yIQfCWLvpq2xV6qUK1ebKQJN+kw7XWAfTYjfRjlc9S+DAgKEvzsRQTeN 4m62+vAPZeYv8aQZqL7zjFxGNXHgSkkU7z27RwoaTyPsozsFFtrandKseftwUr+VH7K+mW6OqxAWfBPqZh1ifg== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > But why do you need to identify rescue workers? What are you trying to > achieve? Hi Tejun, I had a conversation with a colleague of mine. It can be useful to identify and account for all kernel threads. From the perspective of user-mode, the name given currently to the rescuer kworker is ambiguous. For instance, "kworker/u16:9-kcryptd/253:0" is clearly identifiable as an unbound kworker for the specified workqueue which can have their CPU affinity adjusted as you mentioned before. I think if we followed the same naming convention for a rescuer kworker then it would be more consistent. I'll send a patch so it can be discussed further. Kind regards, -- Aaron Tomlin