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 BAA8FC433FE for ; Wed, 5 Oct 2022 01:08:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C2C826B0072; Tue, 4 Oct 2022 21:08:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BDAD46B0073; Tue, 4 Oct 2022 21:08:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ACA286B0074; Tue, 4 Oct 2022 21:08:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 9A1FD6B0072 for ; Tue, 4 Oct 2022 21:08:49 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 61D1480A7D for ; Wed, 5 Oct 2022 01:08:49 +0000 (UTC) X-FDA: 79985111178.04.DB758C0 Received: from r3-17.sinamail.sina.com.cn (r3-17.sinamail.sina.com.cn [202.108.3.17]) by imf22.hostedemail.com (Postfix) with ESMTP id 4C7EBC0010 for ; Wed, 5 Oct 2022 01:08:45 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([114.249.58.228]) by sina.com (172.16.97.27) with ESMTP id 633CD8E900012F56; Wed, 5 Oct 2022 09:07:54 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 98485049289341 From: Hillf Danton To: Valentin Schneider Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Lai Jiangshan , Peter Zijlstra , Frederic Weisbecker , Marcelo Tosatti Subject: Re: [PATCH v4 4/4] workqueue: Unbind workers before sending them to exit() Date: Wed, 5 Oct 2022 09:08:32 +0800 Message-Id: <20221005010832.1934-1-hdanton@sina.com> In-Reply-To: <20221004150521.822266-5-vschneid@redhat.com> References: <20221004150521.822266-1-vschneid@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664932128; 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=u+DW7qcJemv/C7N7R2UgvbJ4pifJ/mBqpN/HSLKA9BA=; b=xZS/gyQT7ZPXz6HUyEnNl1U/fvWoJeRp9vBUhbSnSr12W5t/i39/pQVXn9KIfmSZHP61ve UEWVSkckwllTbWiMIE+hMjP1Bg6Tt831EPZFEcgUS4WpthD4QuUTxCOZMpDXUkPXd92C70 q6cN32nTGPQKXv7L8FpxPqZ/6l6zqU8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.17 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664932128; a=rsa-sha256; cv=none; b=yMzkGFwZBC8BthIKdv4hAmK0XvrcBDIgMGzvte7RGBx11QjnNEtEfpL2uB//uRf+4zkXHO OG7LPUC6YEyU9uP+GQ3IUXhae6+pktk+xY/bZDrbeRWu+5wMwycNKoxb21J/Q5YnmoJ3eb rOuCJeRc9ahKy8VDRakzeh2HUWUrdWs= X-Stat-Signature: d3fcdyytdibp5i7gf419sogpsxc6os8e X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4C7EBC0010 Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.17 as permitted sender) smtp.mailfrom=hdanton@sina.com X-HE-Tag: 1664932125-578269 X-Bogosity: Ham, tests=bogofilter, spamicity=0.026233, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 4 Oct 2022 16:05:21 +0100 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). > Is tick stopped on the isolated CPU? If tick can hit it then it can accept more than exiting kworker. Another option is exclude isolated CPUs from active CPUs because workqueue has other works to do than isolating CPUs. > Prevent this by affining kworkers to the wq_unbound_cpumask (which doesn't > contain isolated CPUs, cf. HK_TYPE_WQ) before waking them up after marking > them with WORKER_DIE. >