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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0496C46467 for ; Wed, 11 Jan 2023 03:34:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 066268E0003; Tue, 10 Jan 2023 22:34:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 016568E0001; Tue, 10 Jan 2023 22:34:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E29458E0003; Tue, 10 Jan 2023 22:34:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CE1E18E0001 for ; Tue, 10 Jan 2023 22:34:12 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8BCC2C0509 for ; Wed, 11 Jan 2023 03:34:12 +0000 (UTC) X-FDA: 80341099944.10.773C08F Received: from r3-25.sinamail.sina.com.cn (r3-25.sinamail.sina.com.cn [202.108.3.25]) by imf14.hostedemail.com (Postfix) with ESMTP id B98D210000C for ; Wed, 11 Jan 2023 03:34:08 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf14.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.25 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673408051; a=rsa-sha256; cv=none; b=k3l4LzfwBgRaRVnM75RN8aR81LFtz8zd8g0Y4d4yJXNoGF8n0FsLIMJIPYwHelPjnjUnlt aSF7ZHD+pC1O8r7MYtwCqKw2ehTGio024i56FjPy6acFtTYhV3TE+OnJVP7T598g2jdSf2 XO99dUsQIeWKed+biblP9alhD1q3Tmw= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf14.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.25 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673408051; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8KAi8j0ocQjVDEw8RKu4cEIQa0R/3I8JqP9zTQ4w68w=; b=6iER9kKQxWEzkjjKs6NlwpXDifIL8/NSzU72ZhidhrM6lOf6/PW8/qzpAIprTdmXtUK4ef RA1M6kV5a03yjnSw6O920FpvMTbXjcT057/7tTW8YTcckSVQbAgvyqrHR5k4BczFB6Qox/ /1aQNnL3P2qWOfGETU9QA+83HT87PFc= Received: from unknown (HELO localhost.localdomain)([114.249.61.130]) by sina.com (172.16.97.23) with ESMTP id 63BE2D73000333A0; Wed, 11 Jan 2023 11:31:01 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 43564554919953 From: Hillf Danton To: Valentin Schneider Cc: linux-kernel@vger.kernel.org, Tejun Heo , Lai Jiangshan , Peter Zijlstra , Frederic Weisbecker , linux-mm@kvack.org, Marcelo Tosatti Subject: Re: [PATCH v7 4/4] workqueue: Unbind kworkers before sending them to exit() Date: Wed, 11 Jan 2023 11:33:51 +0800 Message-Id: <20230111033351.385-1-hdanton@sina.com> In-Reply-To: <20230109133316.4026472-5-vschneid@redhat.com> References: <20230109133316.4026472-1-vschneid@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: B98D210000C X-Stat-Signature: dua33o8a6i16nm4afbg8embxhy3axx71 X-HE-Tag: 1673408048-678067 X-HE-Meta: U2FsdGVkX1+P/qIfWamwQSuUtr5z4DckcVL1eo/ETmMTYxyxuA2/QAOFOcbDP1Ugf+FMBdihWI8J9uO7WuRaTx6W51nnYdXaieRkABnnd3F3AX4av+G7l9l/fOfuP6g0M924hqumZy5Zrd+3UI8pOpolysVVCmPARWy+1CaiyAxYSFM4rbI3rOH7S8hYQ0Qd68Sy0Ui29rKG7KyUfBKAf8BbebsD43ke//uG9h7AvCdHWG7kVbHsnI+2ITb1HCpF3CqAfvsxYjRjljZHOB6zHe8TGlvFWEScIxTq1/gTGBn6ts/X6YJMN6LAam491BD/MryBUlty/CaOujC6F2stkqo0Qh0MZKY9B5GG89nLjc3MeHcmwzUDXlGeIca6B8Yg6s0EIdEIViHu16JajnNUw+wHAirZxa+7IoeSb93wSaDdg0I85FbEntU8iBKvTsGyZIj1cuQyAs5FgByHifTcr1kwI7xbyMijm9+zNBtyEhMknpnL23TWBOAZnmp8P60qWyLMySAqAy0EBgCOoAlklIfOcZmJ1aNDW5KncLzLVrivp3Akr77szlt4UzYw+LFC4znc9IIbpYB6yunLaCEcF8Jk7LKynGiBGZFIU0xqlQQFqxId7eapecY2+hgsiQhISab0apDzyNa7DYhkZOGCD0ckuyMkaheGygHyDE+7xyexnu45fvzbeAFCngC/Nf59ufddcjwu9sr8wYJSNxLGaGWj4bs8cwQxDNCgM5UnKpwQXlDFHf8jLY1Z6n3WFyuB0yzI33eRmJWgGG5r6jUJFCdRcDD4kFOU6Sggb95sJoc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.026996, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 9 Jan 2023 13:33:16 +0000 Valentin Schneider > It has been reported that isolated CPUs can suffer from interference due to > per-CPU kworkers waking up just to die. > > A surge of workqueue activity during initial setup of a latency-sensitive > application (refresh_vm_stats() being one of the culprits) can cause extra > per-CPU kworkers to be spawned. Then, said latency-sensitive task can be > running merrily on an isolated CPU only to be interrupted sometime later by > a kworker marked for death (cf. IDLE_WORKER_TIMEOUT, 5 minutes after last > kworker activity). Given no scheduling in userspace, how is the latency-sensitive task interrupted by woken kworker? If it is due to wakeup preempt then disabling it on isolated CPU for user mode makes more sense, but that should add change to scheduler instead.