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 5B8C4C83F2C for ; Tue, 5 Sep 2023 06:59:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF0BB900007; Tue, 5 Sep 2023 02:59:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DA26D8E001A; Tue, 5 Sep 2023 02:59:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9071900007; Tue, 5 Sep 2023 02:59:56 -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 B53688E001A for ; Tue, 5 Sep 2023 02:59:56 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 89D5C80AD8 for ; Tue, 5 Sep 2023 06:59:56 +0000 (UTC) X-FDA: 81201643992.13.668B361 Received: from out-228.mta1.migadu.com (out-228.mta1.migadu.com [95.215.58.228]) by imf17.hostedemail.com (Postfix) with ESMTP id 98DF040008 for ; Tue, 5 Sep 2023 06:59:54 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fEN2J0jz; spf=pass (imf17.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.228 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693897195; a=rsa-sha256; cv=none; b=7sgz/JH7FT/5bBNSa5rMw+XCxzJ2ya9R/7htfdyHF9yM7dDiA3whaKmlQUD4ZGqpsOhLEz g8tn8Dn2TXe1qub4w0CQ97CoR8uIKTq/Y0seqYx+6K3EHHYmh0aTEAVM/xcJfGBqRQa/v8 nfeJzIypFDHI6746MyB04nZSeKkZc1E= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fEN2J0jz; spf=pass (imf17.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.228 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693897194; 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:dkim-signature; bh=Y7FxXf9l+dp2ORYK03DV31zTbhikfC9PuFPg6OTAs4A=; b=uOxypbjzNBt9nrlH/Ep1eM7y51dOp8xWIO1ZTDO88Z/l8CWEN12RVzPCQsEY8RB9jSFpuW q/Erc0PlxvEAQ3T0H5JI9bikumwtzTNQm4OF9gkYEwFMHgISLluQwdx3CE1nYbe9xzLdaC mCKbgLH5AVTnL7mj0+pEva8yZTjX2RY= Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1693897192; h=from:from: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=Y7FxXf9l+dp2ORYK03DV31zTbhikfC9PuFPg6OTAs4A=; b=fEN2J0jz4PwGM/kRLLUcTTwkpG3uTAIMem1KqX0+lf5tcOnsp/eUj3cTfMTYAcLazWSnxq XqLcJ+LSnJg78ndrR5TbMmtowPAFd+4TtxuKX+dcV/61XthfkxtT/QvwV130hRFXE1HU48 J13WAw0SkT6k5UHrKoQCvRvt/j1XZA4= Mime-Version: 1.0 Subject: Re: [PATCH 2/2] mm: hugetlb_vmemmap: allow alloc_vmemmap_page_list() ignore watermarks X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20230905031312.91929-2-yuancan@huawei.com> Date: Tue, 5 Sep 2023 14:59:09 +0800 Cc: Mike Kravetz , Andrew Morton , Linux-MM , Kefeng Wang Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230905031312.91929-1-yuancan@huawei.com> <20230905031312.91929-2-yuancan@huawei.com> To: Yuan Can X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 98DF040008 X-Stat-Signature: ej81tfb1ysda8n4me3b4i9dscu1yz9ko X-Rspam-User: X-HE-Tag: 1693897194-577045 X-HE-Meta: U2FsdGVkX186SgFvSJBPp4Ae8dIfzdgBfxDsPWayYxRnTQ49nmdcG+UkrJmILOfwVRnWKE6cfHmBe1W6dpTD6BMZ97VAXFpiVweLnxRk6eJGONHVauqec6/iDCZZNUVk7W+2sS95a1x4yQXEjn8DmBfE4VOJ/QRLNdh/a/H30o0E4XDRjTMzDu5ZNBRei6ImhoA9a4S3TIToLM1xXklWf+Wa/e2GY/e6eZOwNWehkc27rPvAh+2rwIAsEIEGYzPWZxaNc2hzpkkoWTvM0dWPg8DahAEK+0m3KtyPfM7myXlKWptVCx9nj7DujmEHNMC1vAp15R0Wn5W7Ol9uTZjGSUTMzPXS0nGggSBO4893s2VGNdTOlkTPtqPEF2Gny2AVzIlB3C2bwsKd8ne4lCcW8+ItyKnHH1rQ0QzWFYSBIngJGProzfXxLhvY2r/dXxyJh8KUCTJtscKCPm7o2J/C3p/HNUS4qAxyyAv3fl/4INhIJn0lfn/INpq32/wrot4fkdhQ9ucWDVH7EwDwru76JxTX+pHv5mtb4ffkpK3k6x85E+UYGRpcdfJAyGXeSAO6SYnxvEQwN3BkoP+t1VeCix4J0ew86QgWogRZ8xH7eHKnqLTcsh+rENZJ1gj4sq7w9E0xtbxIx7JMeD6EJJz7RAX3lCNvuVytraJzh8YLx6SGRTGOkjJQALFHN+xKJj1W9oMTqEndcDbfOtSVz+xoKwctqwpXntqMQygglEejV0IykeLKewa1TgpUKerDSiphqJJNodF4S3ZN90+hq0qho3ZeKFlHoclmj4oZhGgia1uXz8tTnh1d+PS0UvB5HrfprbvZz2O0WAFc4ajEENH6Jd2kncA2a1mrGKo9ANgGf+Bj1UAkks2li5iL0jNeJt+lPgDdMiOZcUVBfMrnKMMq2ah7z9Qhsf//w7un4F8ZmGlOztux503woAHUTiH7aJbu3D/3cpytjp+T4DObztp ZbeXZeY+ lhZE7C5ASdRsjG6QMeUT7xhD+Eqk7iApRfPCdgSpDH74xitqfjBqiziejowc7nATkRPDwDOLR90DeYWk46XKD3uey5lKaukG3K58Zz+70N91qv/4xzKakdznOeer+R13pYSDzGATzcQWBxRTbgA+kl6ZUFFmmrMP1nvTBV/Ibs9MPQFB5a4XPWsJuw/bjoWB5G6am9QpiconEpInMFw8xTw4q4mptpzEJb+Yzb49FA4IJGRYIQa08O4ytvRkbk50JspT3RF5K/0yawvo= 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 Sep 5, 2023, at 11:13, Yuan Can wrote: >=20 > The alloc_vmemmap_page_list() is called when hugetlb get freed, more = memory > will be returned to buddy after it succeed, thus work with = __GFP_MEMALLOC > to allow it ignore watermarks. =46rom the kernel document about __GFP_MEMALLOC, it says: * %__GFP_MEMALLOC allows access to all memory. This should only be used = when * the caller guarantees the allocation will allow more memory to be = freed * very shortly e.g. process exiting or swapping. Users either should * be the MM or co-ordinating closely with the VM (e.g. swap over NFS). * Users of this flag have to be extremely careful to not deplete the = reserve I think we may deplete the reserve memory if a 1GB page is freed. It'll be even worse if recent patchset[1] is merged, because the vmemmap pages will be freed batched meaning those memory will not be freed in a very short time (the cover letter has some numbers). So NACK. * completely and implement a throttling mechanism which controls the * consumption of the reserve based on the amount of freed memory. * Usage of a pre-allocated pool (e.g. mempool) should be always = considered * before using this flag. [1] = https://lore.kernel.org/linux-mm/20230825190436.55045-1-mike.kravetz@oracl= e.com/ >=20 > Signed-off-by: Yuan Can > --- > mm/hugetlb_vmemmap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c > index 0485e471d224..dc0b9247a1f9 100644 > --- a/mm/hugetlb_vmemmap.c > +++ b/mm/hugetlb_vmemmap.c > @@ -386,7 +386,7 @@ static int vmemmap_remap_free(unsigned long start, = unsigned long end, > static int alloc_vmemmap_page_list(unsigned long start, unsigned long = end, > struct list_head *list) > { > - gfp_t gfp_mask =3D GFP_KERNEL | __GFP_RETRY_MAYFAIL; > + gfp_t gfp_mask =3D GFP_KERNEL | __GFP_RETRY_MAYFAIL | = __GFP_MEMALLOC; > unsigned long nr_pages =3D (end - start) >> PAGE_SHIFT; > int nid =3D page_to_nid((struct page *)start); > struct page *page, *next; > --=20 > 2.17.1 >=20