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 E7220C83F3E for ; Tue, 5 Sep 2023 16:52:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51B6F8E0005; Tue, 5 Sep 2023 12:52:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CB548D0001; Tue, 5 Sep 2023 12:52:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B9B48E0005; Tue, 5 Sep 2023 12:52:36 -0400 (EDT) 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 29A328D0001 for ; Tue, 5 Sep 2023 12:52:36 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CDB1CB3C75 for ; Tue, 5 Sep 2023 16:52:35 +0000 (UTC) X-FDA: 81203137470.06.B048842 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf08.hostedemail.com (Postfix) with ESMTP id C0D25160006 for ; Tue, 5 Sep 2023 16:52:33 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=J5YtlzzV; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=iRWdCeE3; dmarc=none; spf=pass (imf08.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693932754; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HOpVu7FAOAEi5tGhm2bC+pLU4kK9U5QMp8h4plkfkCw=; b=hXIK3yVKExObDzo21nqJvC6u4iWvXF163NfNnjdD6gNGVs9xKFOw/98vrh+xSPISImEQCy hRd4hoJ+JTYnn8h4o0cGV1nI0RCr5/VE7pt5FaZsl0tnOWlPXc51Br5971QSI7rqbsB2mW KYoLD4WXOb7Kt+gP9rPPBYR9PkFT5QM= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=J5YtlzzV; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=iRWdCeE3; dmarc=none; spf=pass (imf08.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693932754; a=rsa-sha256; cv=none; b=ZoaxdyIG36yzcYlwlB6uV0ASOm8ifzXEAAtaF2vNOE/00cwakbXBXAqUBlgWdmsoEu7Zg0 R2u6TOGvdEcgFph+fNxDoNzmSRaPWrQRcz3jxWpsmXtanHbtVaFF8rVewLEmUsm9R+2c0o w3KcUkMyyPkWL0iw57qz/v4ts4S17mY= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 223FE1FF15; Tue, 5 Sep 2023 16:52:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1693932750; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HOpVu7FAOAEi5tGhm2bC+pLU4kK9U5QMp8h4plkfkCw=; b=J5YtlzzVXcyQV0r8CRdJm1gnoBob18A/TUUHboh+j8xe6v38f3Chh2ErOYdvQ3l1oNWSIL l/+jJjDIMr5nXiYraB2pJTcPEaEJCGGwPMU96G6HvbtOLbwQXudPFwRihPKJDaf4KV9EKD U+TUO7RpamQIfIVdIKNNmRMk7jRu7bM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1693932750; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HOpVu7FAOAEi5tGhm2bC+pLU4kK9U5QMp8h4plkfkCw=; b=iRWdCeE3AAkYPWf+EIZGFDvyrqgqLNWIs2FJZwd397dsDrooM5aWKFWho9Ksf5NN8Rq6xx Nqy4aDOXR5r3AtBA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id EDFFC13911; Tue, 5 Sep 2023 16:52:29 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id fuUqOc1c92TGJwAAMHmgww (envelope-from ); Tue, 05 Sep 2023 16:52:29 +0000 Message-ID: <703e284d-186a-5699-f06c-761e51115ae0@suse.cz> Date: Tue, 5 Sep 2023 18:52:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH] mm: fix draining remote pageset Content-Language: en-US To: "Lameter, Christopher" , Michal Hocko Cc: "Huang, Ying" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mel Gorman References: <20230811090819.60845-1-ying.huang@intel.com> <87r0o6bcyw.fsf@yhuang6-desk2.ccr.corp.intel.com> <87jztv79co.fsf@yhuang6-desk2.ccr.corp.intel.com> <87v8d8dch1.fsf@yhuang6-desk2.ccr.corp.intel.com> <87msykc9ip.fsf@yhuang6-desk2.ccr.corp.intel.com> <94b0e0c6-a626-46a1-e746-a336d20cdc08@os.amperecomputing.com> From: Vlastimil Babka In-Reply-To: <94b0e0c6-a626-46a1-e746-a336d20cdc08@os.amperecomputing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: C0D25160006 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: sg7ans15wkq7j7nfpwuko3fif95isf66 X-HE-Tag: 1693932753-209473 X-HE-Meta: U2FsdGVkX19JpP2+jnDPFoa+x958R/FkqpCNEKGZ++p93vF4tVkElElGVcUpgHIO05GQIR3Kc2vROgmAZFAOXlO0/dD5t4SwaJpDgIgLUOjzoFiFeSLNCVLcoXkfihsIAhOwAKjbWyFXyUVzg1nvIdFLP8EFryEQe9PGMSatAfj0Bcj4lXPZFud7XV1i9iq4HyLGPFN6OZBzn8usNkBwIJ1lpzb6xIZ2o6YNMxGVp34jvPEgDmIyHW0ppF2S4nQzvXpyMuaP9wRXGJ/0/Gti1xrP8dNpLOC1E3kiL1pHHee851ggbxija+JBnzq3ws/E2IydcYihzWUP1UNExpUGFeVADjTUjoZCxXCz4y6opRVSKoz71R1MAG1B4jzBoIn3QRE2ATTP38hMuzoEci8uLulycm9SOjhZLfRxcHCi/H95X5ielQdP/i5zMpYpFGOnB9V2hpdF4qUjHGHzRH/vYyTYtE/mohYAH2VgARVNH/d9FuQZtLYG5gWUldFKdhIivpEHAkG36jn4sEsxK+C90seCHTyes67Mxk7RRrNNJ0+P2MMMT3JM9raMS+YihI3xXTRkjoYv7SI1/PTYWxspiSDxz2e+dxc1KxgsWOPNrjKPcJlROAAqnS99oEwEYI8NfMWv7MmjDhHnAUSpAFIzCWKpSqCjuAVKUG8S1B4rj9YkXJk1kHTtra5FwJScyKNwWVkDJcQlMVgFx/MZFCOkV6zWbbW1STmNNePzDbYDm18N7TNAq15m7z+WJcV/VY5nJ0qqO8SClFvEgadItybiVj2bUknBrPB25G49hKrRmf0Wt0g0sw7/yNFii0LyXTPwKa3fA0U8DvUdguqbYwYALbRDYD4rrV5PnTJKaqIrFaADZLYs3ovh4btX+xOlfWvluSCogJrG6IAcqjPklXBm1MLJLFzczW1ptbccj+9szw/d0scTsj8qHS5LKv0BWDWZXiTM99N4aBl5xTY4ocU It1c2T9R PjsQ7zpwgNN0npwwdK2G+mCAAnPx0hm8GhPv+lGnbZLdeORScfxdwfMZKjFehLlq8CzEDijzsjlu78Ug/bI34o0hs5o7l6yReeEGBdH+QXNywO0VFzWkzcljKgxxXR1U01vnSt/J3zy5BNlH5pMAFtbya9P9BgGBTYLdhlD5jyhGb0RDix00SLb42ZHla2fUT0dnp 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 8/25/23 19:06, Lameter, Christopher wrote: > On Tue, 22 Aug 2023, Michal Hocko wrote: > >> Yes, this doesn't really show any actual correctness problem so I do not >> think this is sufficient to change the code. You would need to show that >> the existing behavior is actively harmful. > > Having some pages from a remote NUMA node stuck in a pcp somewhere is > making that memory unusable. It is usually rate that these remote pages > are needed again and so they may remain there for a long time if the > situation is right. > > And he is right that the intended behavior of freeing the remote pages > has been disabled by the patch. > > So I think there is sufficient rationale to apply these fixes. I wonder if this the optimum way to handle the NOHZ case? IIUC there we use quiet_vmstat() to call refresh_cpu_vm_stats(). I'd expect if there were pending remote pages to flush, it would be best to do it immediately, and not keep a worker being requeued and only do that after the pcp->expires goes zero. However quiet_vmstat() even calls the refresh with do_pagesets == false. Why do we even refresh the stats at that moment if the delayed update is pending anyway? And could we maybe make sure that in that case the flush is done on the first delayed update in that case and not expiring like this?