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 F2542EB8FAD for ; Wed, 6 Sep 2023 07:26:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7DA3F440147; Wed, 6 Sep 2023 03:26:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 789FB8E0014; Wed, 6 Sep 2023 03:26:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 651C5440147; Wed, 6 Sep 2023 03:26:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 500148E0014 for ; Wed, 6 Sep 2023 03:26:08 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DAC7BC0CFB for ; Wed, 6 Sep 2023 07:26:07 +0000 (UTC) X-FDA: 81205338774.03.4D00506 Received: from out-216.mta0.migadu.com (out-216.mta0.migadu.com [91.218.175.216]) by imf28.hostedemail.com (Postfix) with ESMTP id 81CE4C0017 for ; Wed, 6 Sep 2023 07:26:04 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=VELzSK2n; spf=pass (imf28.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.216 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=1693985166; 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=7VqwzggXz7Ze0MjZp1d3X9HxAYWtB7+KTT+qa99dFBI=; b=CkfOmfn1hZBez3+nmWYIA+FCxPeeDXgMMe0gDdzKljX9XhQaiVlzZOlrKM2L9pPogLMIIq NoLaWglMnQDZ6Vp0cPl3XoKRRT+J6toewUGZkGKh7vM6DQc/p6OqM0ghJ8TYlToP2SMq3Z J4ZVqDOSqY0X1w8L0voQfRIiUDrUJRA= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=VELzSK2n; spf=pass (imf28.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.216 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=1693985166; a=rsa-sha256; cv=none; b=zmrACvg7iGUpkm0Jzy0QTSfBtQ8PyyN8I8YC/jtaXsE5/3YOaLtttHGLeiTEc6vfZ+pdDB turT55NY/CIlCH5mfLM4Pzsk4S8BhFKnrzxsvWrnhvrIhMuTC4PLtk3ddeEyoFn4F+DwRX THCF0xWAwLAcNBJS+Bx3MNuNUgL1QiA= Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1693985162; 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=7VqwzggXz7Ze0MjZp1d3X9HxAYWtB7+KTT+qa99dFBI=; b=VELzSK2nZBNr6enDC8moQmjHLwsbG5thMgCMWbnsQDgkNG6+/eITNsfGrtyLS2i+cIrBCn 9XmAQGCQiaMtn2ldh176uW4AzKndJ0Hkj6TYYk+B4z5B8hm5CHIsJIGrQh4KJi851MznLF uRfRYTg1F03NbGqyrkOXeGD+i9OA5dc= Mime-Version: 1.0 Subject: Re: [PATCH] mm: hugetlb_vmemmap: avoid allocation failure message in alloc_vmemmap_page_list() X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Wed, 6 Sep 2023 15:25:23 +0800 Cc: Mike Kravetz , Andrew Morton , Linux-MM , Kefeng Wang Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230906063423.99395-1-yuancan@huawei.com> To: Yuan Can X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 81CE4C0017 X-Rspam-User: X-Stat-Signature: ozuno9tim5unnt7ideecm5hrm84m1mek X-Rspamd-Server: rspam01 X-HE-Tag: 1693985164-164385 X-HE-Meta: U2FsdGVkX1/WUnSSP7GNWznNmBiFonaneBmVNRMcudlCfXRGTSZzLibx+a7rcd+QGqXHaxjx2B1QU8cZD15hPZhFLF6h/BsD+bVPc7p2T2tca1NNv2wtzBzmaE/YSyy5jf8pGeoArGXyYBMWPFO2AsacKMXJ0RwdpfY7bdGmKiPJJadrT+uQaQcyHXDRXboXVnT8hAs0+UPGMhJSgwmP0I5YKOq6k00ceoF8MiGhkRWyUg8xzFnR5u7BtnzT4nMrI2BwNHvuuBD73Eg677hrA/oIVmGhsmAhaS5G1Q8301GdWqeBtZ+HUety8sXeWDD8mRqW2znOVpDtnHBtaMgUj0gQojwR3RFZ9Wt3Zn3g+626xXu2ixvUNGLAI1l3pHKLgTXM+8r12tZJJ6a5RjHGgajB52Bcw7/Q68uR1nRxoI4MwLIF0F+oElgOScAYb+nb94NsD68Jt2LRCxIA9SLbNHw08nYOkhdB9wUmF3QJ2ECm3zxhVVpTDl4u+MMJ4DB9Ebr75bzzXOBD7wsT8EpvtjGM7a5sTfY8XKawi+NKtXuY87UOgCtMiiZ9MnUiKo4Q0A2MHP0HdLkc9a5DRcUH0ZbVdauGyUWg9fM+Xop4MCahQLDgcXqKDXZm7RDmzr4C40COMBheLZB13u9a13dT0WVAXRDhWPV9UPGYIXX8X49DZEens4ayLQrXQDnWGY1F+e4tW+5BXEqRqSGxenDEfLjPgfYFcCJBW+CAK8QJDi8ngiRkqZ3eL7hUxbMpRth/NIxa7jJ4rVLVmVipfUGllFmPeLXVg0DcdLIe9IA/4e0PLQi4RM+32qU/6XtvwoTZR/GkkgnXaitN0hl3gZZzFY9Cn0q9W/DDUpfkg2rDJF4RSonbJzOScAc+SM7jrd7QMqVoiZ736ZJmt9jVlA73oKlcBrEoDOg4EMz6/UnJpxDmHpX26fCwQCrPVCcckXp5IYp4JYbcYJ4/90eljcb y34nh8Kq j+H8l4Jfew3GxvO/65TSpTA/KTsJa20JyVwvXETwMpBfvjD++6QuTenDaOYO7F+4no6ptcnIfXIK07CDpIV99hPf8JJzmrg1YOv7HWc/t7dx3ATP8sZlv8W3Omlfnj1HagffJSWHlF7ZD2m0n9hu5CyDNWXutkm/Ia9yR40QSJS2Zds7d/HscW/QIDdOEjsfyA8hOZC9xp8Lfqer0WhRCr9v8m02j866Ls8TDNzWCP+JIbTrJgsFO7ZWTy/jWXXmufphv8T2rhtPuiAo= 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 6, 2023, at 15:22, Yuan Can wrote: >=20 >=20 > =E5=9C=A8 2023/9/6 14:52, Muchun Song =E5=86=99=E9=81=93: >>=20 >>=20 >>> On Sep 6, 2023, at 14:34, Yuan Can wrote: >>>=20 >>> When vmemmap pages allocation failed, the hugetlb pages fail to = free, >>> which is not an fatel error, so avoid the allocation failure report = by >>> passing __GFP_NOWARN in gfp_mask. >>>=20 >> You have misunderstand me and Mike. We mean the memory allocation >> in vmemmap_remap_free() which also use __GFP_THISNODE, it has the >> same issue as you fixed in another thread. But the failure of memory >> allocation is not fetal. And it is better to remove __GFP_THISNODE >> as well. >>=20 >> Thanks. >>=20 > Ok, sorry about this, I will send another patch to remove = __GFP_THISNODE in > vmemmap_remap_free, and I would like to know is it ok to add = __GFP_NOWARN in > alloc_vmemmap_page_list()? Do not do this. We need a warning here. Thanks. >=20 > Thanks. >=20 >=20 >>=20 >>> Suggested-by: Mike Kravetz >>> Suggested-by: Muchun Song >>> 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..3fa6b6e2bf45 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_NOWARN; >>> 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 >>>=20 >>=20 > --=20 > Best regards, > Yuan Can