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 961F6EB8FA5 for ; Wed, 6 Sep 2023 04:19:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE4BE900019; Wed, 6 Sep 2023 00:19:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B92C08E0014; Wed, 6 Sep 2023 00:19:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5A5F900019; Wed, 6 Sep 2023 00:19:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9939C8E0014 for ; Wed, 6 Sep 2023 00:19:48 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 65179140B8A for ; Wed, 6 Sep 2023 04:19:48 +0000 (UTC) X-FDA: 81204869256.02.1AB5485 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by imf04.hostedemail.com (Postfix) with ESMTP id 158064000D for ; Wed, 6 Sep 2023 04:19:45 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=OxjyKb+X; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf04.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693973986; a=rsa-sha256; cv=none; b=KbD007UHugGCUrfRgSeX6M4foFdkOswVC9H17GMrqOncKRV1wqVBOjq0MQK/gSURs7AcPv 2xZ2kfNKgYDlS3F3KIF/uRcZtmWbDaj5qulgUJh52NQv1+O29EU+Qse0Lpoz+pG6yRrKee gmjAdIEt5fbo6IowS3Xmef/R5wLtXSU= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=OxjyKb+X; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf04.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693973986; 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=KTOy2cZ0BTLdfN7DEpYP7x8lrwH2SE/cs/7PTCrE4UQ=; b=5cZYGCvofl2wBFQ7zXz78knpfC01p6/pxNgPOpB1nNBPZRWvENJvOcMok0mN8eQrYdSsMe qrzZb3y0AAks1vWN1rSMyM9deK9jp6S9iZ/cbEmWW4H5pKvHqrbeab7jACuyc+N/7f5vlq zj/duYt4Z/z6wT/juXuY8tWq10gOHy0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1693973986; x=1725509986; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=yBIgy9uWf/VMtrwstdvfcWOrvmslXDBJ4tqIjdwS/RM=; b=OxjyKb+Xl0SzkMd1xGpUSQjDyWMqa56u/4BzZs3JQQF4yfNhLwQDgXHa FW3YB7AgxBAWuQnwkKwuF7UY+5EILIMd/IggmsbdK2zx3X5Cv6/mDbA7a 1TSjGKsADNVYs7e8S6oDiPVDK9E/EV8DOhJYTKHmNdMvWkOHEViuIzZIh drSLlYa/fHV9pjZk8T5zoKpmqLgjQFmASuT2IyfsUseacML+S3ObkM3V+ Df6bc86tPRJnjGJoubtF/2OJEq3KXo2v1eB9ToY9N26YxKU/S4K97R1Eq 8QneTgVuPzuHcx+g7nroJ/3IozwrCXXtKi/2l2fc6LJDFnkUN+fGUcpbd Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10824"; a="375870178" X-IronPort-AV: E=Sophos;i="6.02,231,1688454000"; d="scan'208";a="375870178" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Sep 2023 21:19:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10824"; a="741363272" X-IronPort-AV: E=Sophos;i="6.02,231,1688454000"; d="scan'208";a="741363272" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Sep 2023 21:19:41 -0700 From: "Huang, Ying" To: Vlastimil Babka Cc: "Lameter, Christopher" , Michal Hocko , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mel Gorman Subject: Re: [PATCH] mm: fix draining remote pageset 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> <703e284d-186a-5699-f06c-761e51115ae0@suse.cz> Date: Wed, 06 Sep 2023 12:17:27 +0800 In-Reply-To: <703e284d-186a-5699-f06c-761e51115ae0@suse.cz> (Vlastimil Babka's message of "Tue, 5 Sep 2023 18:52:29 +0200") Message-ID: <87zg202aw8.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 158064000D X-Stat-Signature: w8ibgyattn6xp6g5t6k7b6x1aqnrtuqq X-HE-Tag: 1693973985-918379 X-HE-Meta: U2FsdGVkX1+IACSdDvU+87/dA5wj3CFftkKsC2WZmRLiA09gLOzhnMjmgwkx01rJs1H9FB8TsqCG/ZU3qnQIwH+Ecqg7RV3QnWxoJmlgCK5eKFfP+SR0KjXaYZSiZ49cq1ZDgVJTbUm89QiUDrnyx/3KULeHgncWk7Aa4XKjyCp5B7K8YmJKZOInc/KCp9hM0n39Ej/OMA2N12lDaRIOfqWncZaL+K4SdZGHpCg07PPHhv0WfXE5o/0LNVTMmvCbd+uD8p1kNfdTTvNryWXM8vnw1u1LS0OuyWVWwlqMU6whsLIoxyRCfoZaVoCJDWlAFZnGPVql3wXihav5RxBV4D8EMYgJDLkiuarjVJVTd886IAObgirLF27mJG5aeJDKtAXcYwVI9GfROUzesqCFWqIEyZ6RqtVDGHCIMbPp86DzqvDFG3+BkIPu7zny7mel914nW1Rrd8y397JbG4a5OZkMxiiM1bWLdj0fmWCv+OMSEwRA4SfDZsrYIqPaGLaV/XG1Za9jfz1EZGvcdwH/R/yY42+syP+NIEUvx/YbgfEL3+S+Y0hbEGXY+E7Q4B5zCaOK3uJv/aM+A0R2m19SKdjsVguNhv15092ACQhhTlltpPu2No3yI6XUMFwMrEjuZNXGyf9pXC/+jxqfmSMQ9NOA8ckSsJLTnPPSpdAczNPahIrCTx2j8JkrWR3Jkj0XOLJZdMv5SRCZKDNa24kMYlHBUP4kbk7tUUDK/Dd+2LF8txdyIPChPySCiAZCCeyjuJeG8+Gml9vgGXQxZBNVrk1m6l9to+aTPUuJ7eq2bGs9bNHvoGsD9J7N2hqmZMs44Gw8RzKAq162KuKvLMUXsV0VafNJxt7UJ01yrHz6oOkBG8PTBPY8otqUjKLSkcQA+7ScOCZVhNX+BtRgivVZys4ppK0qTwICdbp859+pPyKNvydyIVbciMsR7bR//28b9+U1qPpuQio+w3v3eKj +1pO6VJp EWxnAtebpVby5bhZsIV1hmu8cI+GRibwBRN8BI/IfJhindtbDUhE0wGecEpF3/6IzEZcwCXv8JRe82TNAF+FSrAJbL/uXpbAC82Xhtm5pGlZ1yiiqmiKaiGrrLq8hwB7VAYYj882GpVYfVjse9C1UZonmjQ== 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: Vlastimil Babka writes: > 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? According to commit f01f17d3705b ("mm, vmstat: make quiet_vmstat lighter") and the comments in quiet_vmstat(). The pending worker will not be canceled to avoid long latency of idle entry. > 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? This sounds reasonable. How to identify whether the current CPU is in NOHZ state? Via tick_get_tick_sched()->tick_stopped? -- Best Regards, Huang, Ying