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 5F1B7C32774 for ; Tue, 23 Aug 2022 07:50:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E4456B0073; Tue, 23 Aug 2022 03:50:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 693BE8D0001; Tue, 23 Aug 2022 03:50:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 55AFD6B0075; Tue, 23 Aug 2022 03:50:05 -0400 (EDT) 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 471486B0073 for ; Tue, 23 Aug 2022 03:50:05 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1480A1C6CBB for ; Tue, 23 Aug 2022 07:50:05 +0000 (UTC) X-FDA: 79830083970.22.0B47EBC Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf07.hostedemail.com (Postfix) with ESMTP id 8EE2E4003E for ; Tue, 23 Aug 2022 07:50:04 +0000 (UTC) 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 1C19E5CCE3; Tue, 23 Aug 2022 07:50:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1661241003; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Tzmy0pSRA+QcMUPJOK7gtyRNCVOK3XUksuGeis4aWYQ=; b=ljEkiY86MjjLOgZw3r4zwArfDh9x+EugKc3nklnhxtgiyl2xRF0BGMBBzNevIlb4OuE1FO pqQI97UslW1TpgcxkONLllvJdX6U3FVhriy4EWb08JOb1SJkuZptQNoCH1ufhJ4cwfCVyg TcsSGGvuID1+pBiZj9PbJdhPvkCI9wc= 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 EED2F13AB7; Tue, 23 Aug 2022 07:50:02 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id xGhFOqqGBGNkRQAAMHmgww (envelope-from ); Tue, 23 Aug 2022 07:50:02 +0000 Date: Tue, 23 Aug 2022 09:50:02 +0200 From: Michal Hocko To: Andrew Morton Cc: Liu Shixin , Greg Kroah-Hartman , huang ying , Aaron Lu , Dave Hansen , Jesper Dangaard Brouer , Vlastimil Babka , Kemi Wang , Kefeng Wang , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH -next v2] mm, proc: collect percpu free pages into the free pages Message-ID: References: <20220822023311.909316-1-liushixin2@huawei.com> <20220822033354.952849-1-liushixin2@huawei.com> <20220822141207.24ff7252913a62f80ea55e90@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220822141207.24ff7252913a62f80ea55e90@linux-foundation.org> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661241004; a=rsa-sha256; cv=none; b=dtHQJumU6ZkmNVWcoLYvrqcI2T4AP8LloeT2YUGjM36TSeI4Azmts/z0d7DbrIamy0zKwz TT2lBm4olRxTsCr50FwCQv1Oyf038RW7Ne+/YcWq5COAhS6kEmWbcavR/AODvcsd55BGCV OfcCGtZYOjSYpimrjzH/TJ38ygpFR7o= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ljEkiY86; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661241004; 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=Tzmy0pSRA+QcMUPJOK7gtyRNCVOK3XUksuGeis4aWYQ=; b=WiJG2djmpFIM8HBdhB6tPi0ZGMNWVdPohpsfPUGlXyNEuupwy/AxR5YQH65gVQgM8Xmys8 jGD5dMWzSz6eMOiwoi8cPU5uYh9RbhfWiUrVHrS3/sAxBDiUuauOTiEr/qOKTy7nltRYNz 8TSvv0bncQPI86q3G6fPc3Xsy5J8xxA= Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ljEkiY86; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 8EE2E4003E X-Stat-Signature: h71uico5me5yrrswh9i3yspc4b3ieo66 X-Rspam-User: X-HE-Tag: 1661241004-666134 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 Mon 22-08-22 14:12:07, Andrew Morton wrote: > On Mon, 22 Aug 2022 11:33:54 +0800 Liu Shixin wrote: > > > The page on pcplist could be used, but not counted into memory free or > > avaliable, and pcp_free is only showed by show_mem() for now. Since commit > > d8a759b57035 ("mm, page_alloc: double zone's batchsize"), there is a > > significant decrease in the display of free memory, with a large number > > of cpus and zones, the number of pages in the percpu list can be very > > large, so it is better to let user to know the pcp count. > > > > On a machine with 3 zones and 72 CPUs. Before commit d8a759b57035, the > > maximum amount of pages in the pcp lists was theoretically 162MB(3*72*768KB). > > After the patch, the lists can hold 324MB. It has been observed to be 114MB > > in the idle state after system startup in practice(increased 80 MB). > > > > Seems reasonable. I have asked in the previous incarnation of the patch but haven't really received any answer[1]. Is this a _real_ problem? The absolute amount of memory could be perceived as a lot but is this really noticeable wrt overall memory on those systems? Also the patch is accounting these pcp caches as free memory but that can be misleading as this memory is not readily available for use in general. E.g. MemAvailable is documented as: An estimate of how much memory is available for starting new applications, without swapping. but pcp caches are drained only after direct reclaim fails which can imply a lot of reclaim and runtime disruption. [1] http://lkml.kernel.org/r/YwMv1A1rVNZQuuOo@dhcp22.suse.cz > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index 033f1e26d15b..f89928d3ad4e 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -5853,6 +5853,26 @@ static unsigned long nr_free_zone_pages(int offset) > > return sum; > > } > > > > +static unsigned long nr_free_zone_pcplist_pages(struct zone *zone) > > +{ > > + unsigned long sum = 0; > > + int cpu; > > + > > + for_each_online_cpu(cpu) > > + sum += per_cpu_ptr(zone->per_cpu_pageset, cpu)->count; > > + return sum; > > +} > > + > > +static unsigned long nr_free_pcplist_pages(void) > > +{ > > + unsigned long sum = 0; > > + struct zone *zone; > > + > > + for_each_zone(zone) > > + sum += nr_free_zone_pcplist_pages(zone); > > + return sum; > > +} > > Prevention of races against zone/node hotplug? Memory hotplug doesn't remove nodes nor its zones. -- Michal Hocko SUSE Labs