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 12101C0219B for ; Tue, 11 Feb 2025 11:32:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A92B6B007B; Tue, 11 Feb 2025 06:32:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 657CB6B0082; Tue, 11 Feb 2025 06:32:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 546AD6B0083; Tue, 11 Feb 2025 06:32:05 -0500 (EST) 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 363FA6B007B for ; Tue, 11 Feb 2025 06:32:05 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 13A6614170C for ; Tue, 11 Feb 2025 11:31:52 +0000 (UTC) X-FDA: 83107449264.20.93DBF5C Received: from mail115-80.sinamail.sina.com.cn (mail115-80.sinamail.sina.com.cn [218.30.115.80]) by imf27.hostedemail.com (Postfix) with ESMTP id 220EC40017 for ; Tue, 11 Feb 2025 11:31:48 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of hdanton@sina.com designates 218.30.115.80 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739273510; 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=GZI1+49EVbvEvtRBX6ug9JRC84vUO1++dm3YMtFNmMc=; b=lVP0gslMmC5+kFJgmzXXLjdksmtZNx5vPw1gXt1/lzLk52TCblOcdsYguoFBerb6QAMjLh 9YBLkkCgvs7SGrsGND7j7sHgFw+10pAM85LJVQvcp4DqLdUtTQ8EHk06a8DHOe2PoEiRno /I5IxaDuXMmpEiMZkSyN+3K4CM53rOg= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of hdanton@sina.com designates 218.30.115.80 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739273510; a=rsa-sha256; cv=none; b=Q34Ca95Pc2P93hKrctXb9PRuWO4Hyir+EpY2YiJooiT8DTZzSKGVPAk0fwqxWnK8OW0+g1 Aaxxs3ZR9FU9zSnB33B4nV5i3k7wZdOrySI0wKEAUPDOw44hO6TKq7CW/axNs2wUaXcabA tl30TLwU0c9BX8iJSVWQR3veb9gkpUQ= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([113.88.48.71]) by sina.com (10.185.250.23) with ESMTP id 67AB351D00002393; Tue, 11 Feb 2025 19:31:43 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 7774448913581 X-SMAIL-UIID: EAE02422860949019E53CEEEC6ACCC64-20250211-193143-1 From: Hillf Danton To: Frederic Weisbecker Cc: Marcelo Tosatti , Andrew Morton , Michal Hocko , linux-mm@kvack.org, LKML Subject: Re: [PATCH 6/6 v2] mm: Drain LRUs upon resume to userspace on nohz_full CPUs Date: Tue, 11 Feb 2025 19:31:31 +0800 Message-ID: <20250211113133.2176-1-hdanton@sina.com> In-Reply-To: References: <20250209223005.11519-1-frederic@kernel.org> <20250210105028.2134-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 220EC40017 X-Stat-Signature: m864axg4gp4fi5xke94t8n9b3ngpx3sy X-HE-Tag: 1739273508-131005 X-HE-Meta: U2FsdGVkX1/SORP4ZKuQFBTNUyMo+H2M8VuWdQR0a3pt0omizVb3X8orVJnwmhkHNTGzsyOsTQQVbQeAKuiJm7Sz/IgCwVnCeFD4DVeMBx2XWsH6trIOUXgWrXK1DnY7O7KwggYCtqMZVJsTKMOctaOSFbz9d+6xnkQB8rfiI26gC22vPfPuFsyEpMvw957vCkexIs9WrQui698QUZzRaxOicB8q872fnbdv+SE8Lq7OpZlhxgya8BGUclUKCn3NaiymA+8P/m5gysNa7gB9j/IxegtS2cd6XZddcDOIyoCzTtLnT8v7xQdKOBEgr70sw78fHan0Omg9RSZYZVA3BummZ1CHLl+AD67HIW7Y+YEmKirHy/tIdo0XEBvRXHJaJ5sUypwXR2p1r0oUcdnfwZQGO1hTw6rLr2HymfnuBM//BL+zburdubtMqB65c+iTmNC/X/0y1Ypc3qKD9+ZQRSyKkjLXKTrTu9SNT8TPIvcjbW3vF0/C1DlWT/SiYb5S5Jb9jlhw/suzlFOptNFZXmrZQsjZOjYpndey75S0ho5O2pQnRUVlbVGm1D8DUAHpVorW3Wh3PxWuGl15c/sbGyjdWqFjaC62qEMppisu1ugRzh5jhw1+EDICRgRGsryOnDvjLkYOLwnIloBia1OEYAUGLkV9wjHGd8MFaSHqWEXZ7ZW61Uu0cX+k6J1xBt9l7gnHLGT3Qjj5cgFjJQwJCJkLkWFVxGz+KfMNm+oXLYFeU4zTeL7IY2hMvwdPskSBh1YHI8/bDto5hbbPe/vQShN2QOX92ly/wbuWX/rkRkM8hBObTLQLQ1tjIxgwJtFltR4axjK3crD5zSD2yKmMDGZg7Zq10lZRLF7DKPgtFBG0k6Ds53veN2T8mjrj4Urp3l0BBZlF14u2zaw6oAPOinq5KgNnLokT8gazoisidYQujmlrxXP6grCNonVV3spJ2zjwS1unE5+nhtW5V3r sliMBwKT 5zTwV5rrlm5ejDO2iPR4xJj9K5OwFdrTxDv8GfGL/a6382Z6nasC6++Pt/wuYshA+XRLrnUczTWeZLnMyV3o8Tqj3bFo69qHT18AQDZTfqzRkoAbL/T+/V6dxx718VMHR19hsgPGxZWi54tzXJ5D/b2zMf4NNxc6W0xgD6D26knKAgz8I2Tb1DN3cGYUWaZG6ehQsihhmubZBNWOE0RYdk5a2TPcUe5peo2lv 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: List-Subscribe: List-Unsubscribe: On Mon, 10 Feb 2025 12:46:44 +0100 Frederic Weisbecker > Le Mon, Feb 10, 2025 at 06:50:26PM +0800, Hillf Danton > > On Sun, 9 Feb 2025 23:30:04 +0100 Frederic Weisbecker > > > @@ -769,6 +772,9 @@ static bool cpu_needs_drain(unsigned int cpu) > > > { > > > struct cpu_fbatches *fbatches = &per_cpu(cpu_fbatches, cpu); > > > > > > + if (!housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE)) > > > + return false; > > > + > > > /* Check these in order of likelihood that they're not zero */ > > > return folio_batch_count(&fbatches->lru_add) || > > > folio_batch_count(&fbatches->lru_move_tail) || > > > -- > > > 2.46.0 > > > > Nit, I'd like to add a debug line to test your assumption that > > isolated tasks are pinned to a single nohz_full CPU. > > > > --- x/mm/swap.c > > +++ y/mm/swap.c > > @@ -767,9 +767,10 @@ static void lru_add_drain_per_cpu(struct > > static bool cpu_needs_drain(unsigned int cpu) > > { > > struct cpu_fbatches *fbatches = &per_cpu(cpu_fbatches, cpu); > > + bool yes; > > > > /* Check these in order of likelihood that they're not zero */ > > - return folio_batch_count(&fbatches->lru_add) || > > + yes = folio_batch_count(&fbatches->lru_add) || > > folio_batch_count(&fbatches->lru_move_tail) || > > folio_batch_count(&fbatches->lru_deactivate_file) || > > folio_batch_count(&fbatches->lru_deactivate) || > > @@ -777,6 +778,12 @@ static bool cpu_needs_drain(unsigned int > > folio_batch_count(&fbatches->lru_activate) || > > need_mlock_drain(cpu) || > > has_bh_in_lru(cpu, NULL); > > + > > + if (!housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE)) { > > + VM_BUG_ON(yes); > > + return false; > > + } > > + return yes; > > If the task isn't pinned then the guarantees of nohz_full are broken anyway. > Also if the task migrates it will simply execute the work elsewhere. > Coding in kernel depends on the smart/stupid activity in user space, but the dependence sounds no good. > My only worry is kernel threads. Those are simply ignored in this patchset but > this is not right as they can do allocations. Yet they can't execute anything > on return to userspace... > > Thoughts?