Message ID | 20230811090819.60845-1-ying.huang@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b824:0:b0:3f2:4152:657d with SMTP id z4csp966959vqi; Fri, 11 Aug 2023 02:41:34 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH7TkuZ6fHxITtYbUTPtnf7QDmJfUXKzX90yzRSIRR6CpqtS/Jgc/0hgvQbp58nzvK8GIVN X-Received: by 2002:a05:6a00:1911:b0:687:7a30:deb with SMTP id y17-20020a056a00191100b006877a300debmr1672204pfi.15.1691746894045; Fri, 11 Aug 2023 02:41:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691746894; cv=none; d=google.com; s=arc-20160816; b=Tvw6XWo5DneK+LwW7HHwBOYt1ezGpxXvfyoK2gX45VLtajU+WsEpzjRi6NdlYxoGI9 KWxzulqiJM74j8g8S4BZmx/Nnw0ZSQThFzPl7irhi1+C40+w+dNZZwS/bkEUM2TC8mPy oc2CGlw7WDv6BRZgoDPduI23IuYmIKzCBhKHVq2SGjjHBm5c/U8xzhQApnSQ7jWHhyz3 tfn8eVX4IHHgvG2RcHI/ZQZNFKU5ay9vR/b/RQrTFWSDRGXtb3DTIeE/rGb3n04cTL4f UP13Jl0iaRBRpVnzh7+P3M67ddzbtxO81oDJmzH0KMCMZIqqpDyNqq0ncaf5RC9v3qAy xPOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=tCIRTN89TdovPdvKl0fthpMHCcOT0eprRrlu8+OPaFs=; fh=s6+4IxRzddeSJnVvoPs7LP15fW0IuHkO45yHSXG4siY=; b=aW4ApCDGbr2zXlQt/J0F+6MjH4W7TFDTSV5ue2VzabDLNdrEgrTRp0eKa9bdNURvYE 8KvrEjICeKVFuDXUEt1T1E4M5YGPqDXzuNJW4YNQsxtcB5ZgsBODQ8T7xBvZwKvkioDn 2wcg61u0byqSo3nVNjRYsJ/GGjD2Xi6IFJJuocwz/GD5mfPfUf0+p+w4TBPgraILeHpu +k7xDlEKHA9CFFjgOdvyMut4xA7vy1onIIz3vY3a/1K+9wSwq+0H4Tp0RLDUkDzveSvo W/Hb6WMGsZCLJ6//Vk26GO5/mz2uYAIdKXuTplAF/3TJadeVkrHium0X9cllDxE+VfHT jtUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=fg6ZLzQ6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id eg18-20020a056a00801200b006872b7b1b69si3066624pfb.353.2023.08.11.02.41.19; Fri, 11 Aug 2023 02:41:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=fg6ZLzQ6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234199AbjHKJIe (ORCPT <rfc822;shaohuahua6@gmail.com> + 99 others); Fri, 11 Aug 2023 05:08:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55786 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229888AbjHKJIc (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 11 Aug 2023 05:08:32 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3D9F2D78 for <linux-kernel@vger.kernel.org>; Fri, 11 Aug 2023 02:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691744911; x=1723280911; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=4zCoxQNaeT/5ThBR5TbY5aUu/39R4oWKDboADgANSxI=; b=fg6ZLzQ6JInuqDDeQHoe/6q/p8BqB/xw6e6i6mSAqnq4OoQKh91hq+4y mrzt2QQ5VHvcEayMhUqro/QG0mDxqj8eet3TSq7z4FTfmkELhDfcAAc68 YRQPHLiyg9lW+PHfvVN3UWqsRfCoSOkgifZM6bhWffsmic9CKfUaY+Jen FW4autpeq44oW9IOL75ZlUgK9+mHduyrdIaGUD/gIBlkLpWRlvwdJre// oo/+9E29T5Ro3g7J6OdPgsqPC4EQEGusc68DVTGcwPca4DMYTbkwRPmno hmm9Ns3rbAB+lqxl0tKZrfSSZuTy1L0GBuibCWnSL0pBAKtTuWG+Ik/TQ w==; X-IronPort-AV: E=McAfee;i="6600,9927,10798"; a="361776277" X-IronPort-AV: E=Sophos;i="6.01,165,1684825200"; d="scan'208";a="361776277" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Aug 2023 02:08:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.01,202,1684825200"; d="scan'208";a="876091008" Received: from jallred-mobl.amr.corp.intel.com (HELO yhuang6-mobl2.ccr.corp.intel.com) ([10.255.28.249]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Aug 2023 02:08:32 -0700 From: Huang Ying <ying.huang@intel.com> To: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Huang Ying <ying.huang@intel.com>, Christoph Lameter <cl@linux.com>, Mel Gorman <mgorman@techsingularity.net>, Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@kernel.org> Subject: [PATCH] mm: fix draining remote pageset Date: Fri, 11 Aug 2023 17:08:19 +0800 Message-Id: <20230811090819.60845-1-ying.huang@intel.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773925191185133666 X-GMAIL-MSGID: 1773925191185133666 |
Series |
mm: fix draining remote pageset
|
|
Commit Message
Huang, Ying
Aug. 11, 2023, 9:08 a.m. UTC
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.
This is fixed via guaranteeing that the vmstat updater worker will
always be re-queued when we are waiting for the timeout.
We can reproduce the bug via allocating/freeing pages from remote
node, then go idle. And the patch can fix it.
Fixes: 7cc36bbddde5 ("vmstat: on-demand vmstat workers V8")
Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Michal Hocko <mhocko@kernel.org>
---
mm/vmstat.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Comments
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? > This is fixed via guaranteeing that the vmstat updater worker will > always be re-queued when we are waiting for the timeout. > > We can reproduce the bug via allocating/freeing pages from remote > node, then go idle. And the patch can fix it. > > Fixes: 7cc36bbddde5 ("vmstat: on-demand vmstat workers V8") > Signed-off-by: "Huang, Ying" <ying.huang@intel.com> > Cc: Christoph Lameter <cl@linux.com> > Cc: Mel Gorman <mgorman@techsingularity.net> > Cc: Vlastimil Babka <vbabka@suse.cz> > Cc: Michal Hocko <mhocko@kernel.org> > --- > mm/vmstat.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/mm/vmstat.c b/mm/vmstat.c > index b731d57996c5..111118741abf 100644 > --- a/mm/vmstat.c > +++ b/mm/vmstat.c > @@ -856,8 +856,10 @@ static int refresh_cpu_vm_stats(bool do_pagesets) > continue; > } > > - if (__this_cpu_dec_return(pcp->expire)) > + if (__this_cpu_dec_return(pcp->expire)) { > + changes++; > continue; > + } > > if (__this_cpu_read(pcp->count)) { > drain_zone_pages(zone, this_cpu_ptr(pcp)); > -- > 2.39.2
Hi, Michal, Michal Hocko <mhocko@suse.com> 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. I will update the change log to include this. -- Best Regards, Huang, Ying >> This is fixed via guaranteeing that the vmstat updater worker will >> always be re-queued when we are waiting for the timeout. >> >> We can reproduce the bug via allocating/freeing pages from remote >> node, then go idle. And the patch can fix it. >> >> Fixes: 7cc36bbddde5 ("vmstat: on-demand vmstat workers V8") >> Signed-off-by: "Huang, Ying" <ying.huang@intel.com> >> Cc: Christoph Lameter <cl@linux.com> >> Cc: Mel Gorman <mgorman@techsingularity.net> >> Cc: Vlastimil Babka <vbabka@suse.cz> >> Cc: Michal Hocko <mhocko@kernel.org> >> --- >> mm/vmstat.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/mm/vmstat.c b/mm/vmstat.c >> index b731d57996c5..111118741abf 100644 >> --- a/mm/vmstat.c >> +++ b/mm/vmstat.c >> @@ -856,8 +856,10 @@ static int refresh_cpu_vm_stats(bool do_pagesets) >> continue; >> } >> >> - if (__this_cpu_dec_return(pcp->expire)) >> + if (__this_cpu_dec_return(pcp->expire)) { >> + changes++; >> continue; >> + } >> >> if (__this_cpu_read(pcp->count)) { >> drain_zone_pages(zone, this_cpu_ptr(pcp)); >> -- >> 2.39.2
diff --git a/mm/vmstat.c b/mm/vmstat.c index b731d57996c5..111118741abf 100644 --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -856,8 +856,10 @@ static int refresh_cpu_vm_stats(bool do_pagesets) continue; } - if (__this_cpu_dec_return(pcp->expire)) + if (__this_cpu_dec_return(pcp->expire)) { + changes++; continue; + } if (__this_cpu_read(pcp->count)) { drain_zone_pages(zone, this_cpu_ptr(pcp));