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 ACCA6C46467 for ; Wed, 11 Jan 2023 00:09:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 371F38E0002; Tue, 10 Jan 2023 19:09:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 321C98E0001; Tue, 10 Jan 2023 19:09:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 210738E0002; Tue, 10 Jan 2023 19:09:51 -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 11CF18E0001 for ; Tue, 10 Jan 2023 19:09:51 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D2A1BA031E for ; Wed, 11 Jan 2023 00:09:50 +0000 (UTC) X-FDA: 80340584940.19.7E1E3EE Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf11.hostedemail.com (Postfix) with ESMTP id 2A9DE4000B for ; Wed, 11 Jan 2023 00:09:48 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=f98Sk2Xy; spf=pass (imf11.hostedemail.com: domain of frederic@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=frederic@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673395789; a=rsa-sha256; cv=none; b=BAp7ZPYbOSAGu8b8Q1y5+CY7bM2emG1BcdnBOR0xH0VuzB2guAaNS+x1Yj2/iYsqzDzh1C kwvv4J0jsNmDLNs0a7QpxJ0uO+4uWs5Ic4vfO+YeEGqszTXUz1HqKgZ8XTeAc4D55IFrpP gFtOhoC0HUEOBs2z+ssMJwcyU0Fnkso= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=f98Sk2Xy; spf=pass (imf11.hostedemail.com: domain of frederic@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=frederic@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673395789; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FXfk8ftwSNGgv/1hULLiMJsc5+GtTJx9AaWQoc4dYWQ=; b=hYeCRYbZkZssTvm8uJ+Oq/6xc7nUZSjOfdvhHaHEJagbxRPHB/Jv8XXUraf5rXNiEvPbP3 jIQainIzc/f5CiN07jxqcQ9j/6fxJ9awy3TRe4Qwytjs9SKtre/QmBgWvSSf2YI9iLiX91 Q719wUQmTbzXdng3ximOMUwDV3IlMnY= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 542B0B8196F; Wed, 11 Jan 2023 00:09:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97DC7C433D2; Wed, 11 Jan 2023 00:09:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673395786; bh=HB4XAeRTp61OHmgdavBJ9HANdrwwjdFDvzdf27/ncI0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=f98Sk2XywpmZWPGw1IkbIboSOQ+FWx69/4SBP3t0uvElFQwY4XOb+bZIBEsJhwgGp SK3lGO7IUT6zedtonkiT5kba7XdCBDjG277KeuCLf+wRbs3uGXQ4rCfo5p/F5rdkJx J7d/zLBQtvJ50osPgbqKd4jVJ51aqvEtLtiLAXJ8TCVaqpgW/lzgqh4+Ytw/6erJLs GaODBbyufi/afVqoQDmYUHuXMJ0iKVMSVUZ9+OhEAnwKwsATz7EmCmcDvkrqhW95x8 iTddLmAom+SzggiuOxy6btXukmwIjSidUIzUK/YPpmR0Ldj90YUzIP3dSb8U/zWaqF nz0n5VI99uH7g== Date: Wed, 11 Jan 2023 01:09:43 +0100 From: Frederic Weisbecker To: Hillf Danton Cc: Marcelo Tosatti , atomlin@atomlin.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v13 3/6] mm/vmstat: manage per-CPU stats from CPU context when NOHZ full Message-ID: References: <20230110151901.402-1-hdanton@sina.com> <20230110235822.456-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230110235822.456-1-hdanton@sina.com> X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 2A9DE4000B X-Stat-Signature: zfjf74m9pegaeksti1b984wems3end3w X-HE-Tag: 1673395788-809642 X-HE-Meta: U2FsdGVkX19eE8vzMMts7CQFZHjvUP0qH7B7nc7krQWfIrhaozddKfN8AkCBDweA90WgTGJvqk3u86OJBln8/RydqnnGPBLEkAc3NPmFAR4wxt2gKiLLrfOWs+Oy3BmmYvdx9k2XAyfMJwK9BDVBQw/acORZfxQ9BGeP7Bm9VXwsRKChG3uw+66U5+eQPIsNPxhu1Bfdoo8OHLPcrKVnFaOcIA7OvRHMYoLQMIzMkxO7uhxgtteXH+AT2aip6RRDisOZVfyz7vLOAQyZaQFWED3/sniAzkPupEdpCZ5vYFhVYI0Bu8Rr1/wXkMSqz1G/k68465szQAP/G5siC+5w7OlxquqLrY5j35Uti4oJHL1iDPQjMvyojEY6SsW1w0UYKNGau350YVzKkTbA7U2BL+JyrxgCB7EnJATEH54RPlqJX4KasiWjE6GJ+UaB3W/Q/O7sFChI2XXoBQW52Vyi6VDzWF77hZ3XQKt30bosr2lkqdWZqReL/DGfYfBY+3KE1ptoqAKwghfml4XD49vYz1+yGEli8iRE+YX+LrfQhkbRCTDPVPaY03isGEfApNxu6S/gnZJi8CT+Hhd+5CJgTg0enFLb8w1cGO/wezYtA2kQJoUCUYPwxNaz0pKosgAeKIcIFe3xad7MYdIM4DMg0AszycTuVY2T+9HSunSB0br4SYxh7gwDxnqzBmXRh6DBGuvIKnr2A1R+EzcOqgT3QUFDXbxgKp3rVb5Cg8/M+gpB7PGB0qOnGqaQwleWrrrrDFbkefFtC+mCpHuUoSS3Y54//qEYeI43b4rTVNmotiPmAM2TirCIS4IPMPFaYSo7p+5QDcCL6+rtUsQnyVh2Dny9B7FLtBbWz0C0HqhChEeKgwbPMywR3lleBlyk77m+LUzYVFyYdIHjTdq0bApP6F+edWIOX5HEbiPWN7rszRTKS66oTG+bVMQYSlocVSKbyvs0C/I/T7ihHEs7DBK wxT+3Boj ygynaeXOv2sknXDlyQMCvJK1q1A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jan 11, 2023 at 07:58:22AM +0800, Hillf Danton wrote: > On 10 Jan 2023 17:12:22 +0100 Frederic Weisbecker > > On Tue, Jan 10, 2023 at 11:19:01PM +0800, Hillf Danton wrote: > > > On Tue, 10 Jan 2023 08:50:28 -0300 Marcelo Tosatti > > > > On Tue, Jan 10, 2023 at 10:43:56AM +0800, Hillf Danton wrote: > > > > > On 9 Jan 2023 11:12:49 -0300 Marcelo Tosatti > > > > > > > > > > > > Yes, but if you do not return to userspace, then the per-CPU vm > > > > > > statistics can be dirty indefinitely. > > > > > > > > > > Could you specify the reasons for failing to return to userspace, > > > > > given it is undesired intereference for the shepherd to queue work > > > > > on the isolated CPUs. > > > > > > > > Any system call that takes longer than the threshold to sync vmstats. > > > > > > Which ones? > > > > > > If schedule() occurs during syscall because of acquiring mutex for instance > > > then anything on the isolated runqueue, including workqueue worker shepherd > > > wakes up, can burn CPU cycles without undesired interference produced. > > > > The above confuses me. How others tasks would help with syscalls that take too long too > > service? > > Given no scheduling in userspace, no chance for other tasks to interfere > after returning to userspace, on one hand. > > Upon scheduling during syscall on the other hand, it is the right time > to sync vmstats for example. But no vmstats can be updated without works > queued by shepherd. > > In a nutshell, no interference could happen without scheduling, and how > work is queued does not matter. So the current shepherd behavior is prefered. I'm still confused... We want to avoid the shepherd because it may queue the vmstat work while the task wants to run noise-free in userspace. > > > > > > > > > > Or a long running kernel thread, for example: > > > > > > It is a buggyyyy example. > > > > > > > > https://stackoverflow.com/questions/65111483/long-running-kthread-and-synchronize-net > > > > I can imagine a CPU spending most of its time processing networking packets > > through interrupts/softirq within ksoftirqd/NAPI while another CPU process > > these packets in userspace. > > > > In this case the CPU handling the kernel part can theoretically never go to > > idle/user. nohz_full isn't optimized toward such job but there is nothing > > to prevent it from doing such job. > > A simple FIFO task launched by an administrator can get a CPU out of scheduler's > control for a week, regardless of isolation. Sure. But, what do you mean by that exactly? Thanks.