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 B2576C00140 for ; Wed, 24 Aug 2022 10:06:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4511B6B0073; Wed, 24 Aug 2022 06:06:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D9856B0074; Wed, 24 Aug 2022 06:06:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 27A2A940007; Wed, 24 Aug 2022 06:06:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 126DC6B0073 for ; Wed, 24 Aug 2022 06:06:22 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D39B08094E for ; Wed, 24 Aug 2022 10:06:21 +0000 (UTC) X-FDA: 79834056162.23.D8F737B Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf07.hostedemail.com (Postfix) with ESMTP id 9A1EF40044 for ; Wed, 24 Aug 2022 10:06:19 +0000 (UTC) Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4MCM8439qbzXf1Y; Wed, 24 Aug 2022 18:01:56 +0800 (CST) Received: from dggpemm100009.china.huawei.com (7.185.36.113) by dggpemm500020.china.huawei.com (7.185.36.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 24 Aug 2022 18:05:59 +0800 Received: from [10.174.179.24] (10.174.179.24) by dggpemm100009.china.huawei.com (7.185.36.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 24 Aug 2022 18:05:58 +0800 Subject: Re: [PATCH -next v2] mm, proc: collect percpu free pages into the free pages To: Michal Hocko References: <20220822023311.909316-1-liushixin2@huawei.com> <20220822033354.952849-1-liushixin2@huawei.com> <20220822141207.24ff7252913a62f80ea55e90@linux-foundation.org> <6b2977fc-1e4a-f3d4-db24-7c4699e0773f@huawei.com> CC: Andrew Morton , Greg Kroah-Hartman , huang ying , Aaron Lu , Dave Hansen , "Jesper Dangaard Brouer" , Vlastimil Babka , "Kemi Wang" , Kefeng Wang , , From: Liu Shixin Message-ID: Date: Wed, 24 Aug 2022 18:05:58 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.24] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm100009.china.huawei.com (7.185.36.113) X-CFilter-Loop: Reflected ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=liushixin2@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661335580; a=rsa-sha256; cv=none; b=Wi5CEM3ka/+bpEac84nLPJHfvG+4HwNkJeOCiEGjvFgikQdAehfhUUQubI5X08DPrzLM9+ 7arG8UrJJgYNteqdBCsIkNLzhrwcCOujlZPa+o+tMZY7T88eIfcQqu1oVNYV0yFqP7Eqie WV1rx/JdWAThbKF6THsCeCGRC6U3wU8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661335580; 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; bh=1MVFsMy1jKfIUHosIyURIgi4oIagw3Ei+j0t1vNRjN0=; b=FM6zMH7+aPYXxST9MYuz4f0wy3q86/kiROk0Qq3j/7EiMvDMOK+HCEGua8tAKIXXPS9QSe 8LJUaEoHPwzy+CVyPCYaVNXPoAEDZUxhC6d0UW5OoW8nQtGv9VwJxy8xD9KimGr8a4I0t1 cvju0kXMJHbXMLTATgbwdSU/Su1cUuY= Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=liushixin2@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-Rspam-User: X-Rspamd-Queue-Id: 9A1EF40044 X-Rspamd-Server: rspam05 X-Stat-Signature: kounosnrmsjy8hnwtzk9xmcb98gbi8g9 X-HE-Tag: 1661335579-922022 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 2022/8/23 21:37, Michal Hocko wrote: > On Tue 23-08-22 20:46:43, Liu Shixin wrote: >> On 2022/8/23 15:50, Michal Hocko wrote: >>> 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? >> This may not obvious when the memory is sufficient. However, as products monitor the >> memory to plan it. The change has caused warning. > Is it possible that the said monitor is over sensitive and looking at > wrong numbers? Overall free memory doesn't really tell much TBH. > MemAvailable is a very rough estimation as well. > > In reality what really matters much more is whether the memory is > readily available when it is required and none of MemFree/MemAvailable > gives you that information in general case. > >> We have also considered using /proc/zoneinfo to calculate the total >> number of pcplists. However, we think it is more appropriate to add >> the total number of pcplists to free and available pages. After all, >> this part is also free pages. > Those free pages are not generally available as exaplained. They are > available to a specific CPU, drained under memory pressure and other > events but still there is no guarantee a specific process can harvest > that memory because the pcp caches are replenished all the time. > So in a sense it is a semi-hidden memory. > > That being said, I am still not convinced this is actually going to help > all that much. You will see a slightly different numbers which do not > tell much one way or another and if the sole reason for tweaking these > numbers is that some monitor is complaining because X became X-epsilon > then this sounds like a weak justification to me. That epsilon happens > all the time because there are quite some hidden caches that are > released under memory pressure. I am not sure it is maintainable to > consider each one of them and pretend that MemFree/MemAvailable is > somehow precise. It has never been and likely never will be. Thanks for your explanation. As you said, it seems that merge these memory into MemFree/MemAvailable directly may affect the performance under memory pressure. That sounds reasonable. But since these memory is also free memory that can be uesd and is large, I think we should still provide a statistic for the user. Perhaps add a new statistic is better? Thanks,