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 852B8EE4996 for ; Mon, 21 Aug 2023 08:32:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C91E86B007D; Mon, 21 Aug 2023 04:32:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C419A6B007E; Mon, 21 Aug 2023 04:32:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B09228D0001; Mon, 21 Aug 2023 04:32:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A20126B007D for ; Mon, 21 Aug 2023 04:32:35 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8084AB21F2 for ; Mon, 21 Aug 2023 08:32:35 +0000 (UTC) X-FDA: 81147445470.26.492C3AD Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by imf09.hostedemail.com (Postfix) with ESMTP id C1689140031 for ; Mon, 21 Aug 2023 08:32:32 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ewl6rQa9; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.65 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=1692606753; 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=LWqnwfgikshDGgfdgOBc40z2j50cFLczH/++Xzl+WVA=; b=daf8+a4XK6jU0L+xxDAKuPDwqC7zZ4p10iPregYtWHrfn/7ZleQh5eBIgp0iFGBnUpSI51 Pq+d9jSPaNIAGiItFaOGWuqxXosmFmVKlYZ50V117AXzoRhxTDcX+Hdgb1rQ3O9+QYroVK UA48/JpYPjEydnZg4dAoOXZA0vwx3nA= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ewl6rQa9; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.65 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692606753; a=rsa-sha256; cv=none; b=IhXpm152V/LM5JRxczFO7T2eY3fIvArkbrwWpBRG5MecpsRJAMuI0rLboGOGqq7+t5o6lO UfhkWr5bdJVWc6dWv8cDbOcQ7DFUQCQiUnDCrw7lDWwl+XQKfr1GIzc43G/iMmz2HZlgQa aqiEVsLMW5bx+frG9N2Y15Uj1j7eIxo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1692606753; x=1724142753; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=nJtasNz7sa4gjo3p4OPIrhfF9GMcxzPE73svQO2Q3Nk=; b=ewl6rQa9m/+xJi01bfal8uiv4QZTkZT6rC8A0lqo4NbSlAsIuRGYzOqj 3b0iKJk5jVLwDjY/O+gRyzx6J45Ej8GMJ7Bc7spzGj2NpimT/Z2vQ96gx YVUevt0OtbUNPM8FK8WKyCVzr8Ybmw4mZEULfxwh/pDRpb9VYipvAQmIg lArTD1acPfJMc3o/kFMmThTAWL04lg2IGqiO2D/5AcohawaA3U2nVAGnk zxXPCPwXv0OIBWJnT25r/FcgHntCNeZKr97CaGtMnSKrlhbLwFFZthS5t rSG8Dnz8q3R11cjHN1It+AFB+fb6QaKTEfzX0BeEfFsupWmPrZeyJy+F0 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10808"; a="377271017" X-IronPort-AV: E=Sophos;i="6.01,189,1684825200"; d="scan'208";a="377271017" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Aug 2023 01:32:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10808"; a="859404590" X-IronPort-AV: E=Sophos;i="6.01,189,1684825200"; d="scan'208";a="859404590" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Aug 2023 01:32:28 -0700 From: "Huang, Ying" To: Michal Hocko Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christoph Lameter , Mel Gorman , Vlastimil Babka 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> Date: Mon, 21 Aug 2023 16:30:18 +0800 In-Reply-To: (Michal Hocko's message of "Mon, 21 Aug 2023 09:55:27 +0200") Message-ID: <87v8d8dch1.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-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: C1689140031 X-Stat-Signature: gbahbj1n958ii7cqas6479ezhusjk7ib X-Rspam-User: X-HE-Tag: 1692606752-35943 X-HE-Meta: U2FsdGVkX1/EYY/hWCmwTDYRKM+hG8/D5qKuTf8sih+5qsVnzjhQ6zP0ecHjfNVpli6Uc2k7ZX9pPfIkE5KqnhgEsyW2WdtKbQQMKL4n7cRUjJIw9Z/rncMGMT5cJ4BOlRxnQNrw4hq56NTaBbq7hQXSoXpN96cZPmasfkAQZ5LIHsgBithjNJme5gFUSgOheZS3NHpwkvKRIFKuEhMNCzGPLKip6KxQ3sXqrt/pqgtyQNriOCWtJCpYJSPqi+aSsUWtdIKHKO51wV4wAmNOaoSCdG5fcQrnNLnCvB3xQLsD0RRt21uSiWkFSFTvGDR2xRxh9UMcranEIXS7k57s1TvbgPnvNWg5TjWMW4YCTCls57wuiowGDdwF1wRfBz2oxA84V2WHyTsywnqncOKcqU5Ohc5f06dLXCgVft0XqibPbmZI4w88L3LYWBYbxkUHivyc4sVTCzhy5kkaZe7juk4iUNg0vHPdAoxpf2exESAhwbxxSPgL9HRvSXAkvlWDaSLe3KOo3czOJlgMP8IQswyut92d8a8H0wUMF4kX4Hds2TLdEBsw0vE/Yl9wcslFE8KH5yYLqQZRk3+/34jwdwdCD2YzGPZklFjij8MBcpJ/dTTylBc7dx6sFgiuvlFbBP8CVdeMH+0t2dc969l3Z5oEQ6EjVHbGknTNbkq1CiAf50Mqkhb3ceTiUk6j8k/244K7F+9FNLeEMOsZqC+nLtgLv5Mc2RaCwlGZv8lYuJlm6DJyXJphi6nycZk/Np1g2nD/OP3PRSbOwTTGcxMHtzKy7o/biyMUMZD02ELRFkf2jJu1UyTpdxFd8Wa28upjxeX1A07WczZnq1uIALJ50lMN1df77O0gkpLxIs59YOysTAUUfkbCNLY92kvuat8B7jQcHyhDDKau+gUA3Uiffabbx23Zf4CrdsBvg6yyKZLFf8GFEhk8C7tAMbl682NzEVMWVUoG6RbF4kGvl3l TmdFRU2D qY18bML9aD6b1vTyJydij6/9XIb0TLvTcUVk+U4/cpUZ0TO5CBi080lNulL6A63N1cFpWEA7EkFhoznr9DPJtAg5KjIEFFY4kuXuXHr4MQlHZGkWcmSk/M02a96vHF8V5kRH1BOkjGYzqfG4pZVqUqnWUcdCZjVRnpuOqSj93tzRLA6HyUb1tfp1Lq8bRnmVv1q+qosZjbBS+bh0= 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: Michal Hocko writes: > On Wed 16-08-23 15:08:23, Huang, Ying wrote: >> Michal Hocko writes: >> >> > On Mon 14-08-23 09:59:51, Huang, Ying wrote: >> >> Hi, Michal, >> >> >> >> Michal Hocko writes: >> >> >> >> > On Fri 11-08-23 17:08:19, Huang Ying wrote: >> >> >> If there is no memory allocation/freeing in the remote pageset after >> >> >> some time (3 seconds for now), the remote pageset will be drained to >> >> >> avoid memory wastage. >> >> >> >> >> >> But in the current implementation, vmstat updater worker may not be >> >> >> re-queued when we are waiting for the timeout (pcp->expire != 0) if >> >> >> there are no vmstat changes, for example, when CPU goes idle. >> >> > >> >> > Why is that a problem? >> >> >> >> The pages of the remote zone may be kept in the local per-CPU pageset >> >> for long time as long as there's no page allocation/freeing on the >> >> logical CPU. In addition to the logical CPU goes idle, this is also >> >> possible if the logical CPU is busy in the user space. >> > >> > But why is this a problem? Is the scale of the problem sufficient to >> > trigger out of memory situations or be otherwise harmful? >> >> This may trigger premature page reclaiming. The pages in the PCP of the >> remote zone would have been freed to satisfy the page allocation for the >> remote zone to avoid page reclaiming. It's highly possible that the >> local CPU just allocate/free from/to the remote zone temporarily. > > I am slightly confused here but I suspect by zone you mean remote pcp. > But more importantly is this a concern seen in real workload? Can you > quantify it in some manner? E.g. with this patch we have X more kswapd > scanning or even hit direct reclaim much less often. >> So, >> we should free PCP pages of the remote zone if there is no page >> allocation/freeing from/to the remote zone for 3 seconds. > > Well, I would argue this depends a lot. There are workloads which really > like to have CPUs idle and yet they would like to benefit from the > allocator fast path after that CPU goes out of idle because idling is > their power saving opportunity while workloads want to act quickly after > there is something to run. > > That being said, we really need some numbers (ideally from real world) > that proves this is not just a theoretical concern. The behavior to drain the PCP of the remote zone (that is, remote PCP) was introduced in commit 4ae7c03943fc ("[PATCH] Periodically drain non local pagesets"). The goal of draining was well documented in the change log. IIUC, some of your questions can be answered there? This patch just restores the original behavior changed by commit 7cc36bbddde5 ("vmstat: on-demand vmstat workers V8"). -- Best Regards, Huang, Ying