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 C04D3C3DA61 for ; Wed, 24 Jul 2024 09:58:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 26FFE6B007B; Wed, 24 Jul 2024 05:58:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 21DBE6B0082; Wed, 24 Jul 2024 05:58:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 06F856B0096; Wed, 24 Jul 2024 05:58:50 -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 DBFA26B007B for ; Wed, 24 Jul 2024 05:58:50 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6B67C1C14F1 for ; Wed, 24 Jul 2024 09:58:50 +0000 (UTC) X-FDA: 82374197220.07.EAD078B Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) by imf13.hostedemail.com (Postfix) with ESMTP id 99D1120023 for ; Wed, 24 Jul 2024 09:58:48 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QNVTtxod; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.173 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721815093; a=rsa-sha256; cv=none; b=Dpqt5TS47ZNdn5wVVsps0xDEVdb891k5T/EBl4lEyQBHnYeIZVIL2TniA3ZyLVPdkU7VYK LcB1l8GM25yjTOlJ8L3cqL4phU4Qm0R+HRsyRbra/1WHMKjRo/C5v9bqRzNvWD21ULjo10 uSJfmdbOQ6yz4zuz4eq+qJXY2xHAorY= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QNVTtxod; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.173 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721815093; 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=icEcTqINznzODsWfdqc/Q8asd/h63sMaAFn10AYwBYc=; b=0l+N4CgEvTyb7Rd9W/q2fInA0/FLlYm2Shf5Q61vRZ7nZOxS77vfyQkRGB3S8N1z/33j3R ua2UNC0oCJOlfK3931iSvNIhBZa/Jf40ujkG0BnHbAgHbOvJwnLopwRUcQNyQ2K7CHlTr6 3xQec4b9ShgUhsj7Igjkp2Q+KPnc03w= Received: by mail-vk1-f173.google.com with SMTP id 71dfb90a1353d-4f52bd5b555so522051e0c.1 for ; Wed, 24 Jul 2024 02:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721815127; x=1722419927; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=icEcTqINznzODsWfdqc/Q8asd/h63sMaAFn10AYwBYc=; b=QNVTtxod/wx/9vDb6x1FCDCG6ezOmMMM4t4grMWbr2vac7lyJdH5gdfNjW1hJCVnmG pKkMkh5H1pqFZovOuuOTQTsy++H4xLbbU88BuwYFHw5xWS71zW9x82ZyxUy1WWIXHXBo OijTePe0v7toInDJPU6VIp3g0TONf4b3swY1oRjCjiN0+jqB+1GyKE5KMvEZqx8enIsL qIyF/3KfJIaWsMrWWLx2kFZGY2jk5EmOWQc1g5M0Shr0fxqE5paYkpI/ABK7zJtrQ/Ny OYRJfAZMgFjd12CEDl1REFoC8+0SaBwhGH74yAsripJU6gXJWHTUp1CfaczRy1dcCkLt redA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721815127; x=1722419927; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=icEcTqINznzODsWfdqc/Q8asd/h63sMaAFn10AYwBYc=; b=aqJL0Dh7CZqOnBa21u1qTdGX22BsCVJYf+7zr7MhxQJdjNCbCfu10hd/fV+T1CyDw9 9TPxzixSqUPIyJ8kjp/6EqbA1DpqAd1IyLIowFVTuSJJmmc2fMkXGFtb+LGWegDoeQ/q 6mBUG3qodERFCHOa3pBmjJpatNJP/tMy10L6yQqZBGN1ajExInIiHLKNi2zgWUi0DG9L PUPMLTbUUsm974AXdxkL+nCLW5moOL8z7Z0W4ja0+oFG1EIIC+1rbth1Nq4Qg8OYiokV djZO5Odp1NPqdipx2sIFtATQgOmlToyWhPcP9lDmEy7G6ah4UN7I6ikMOLCwyEtk7exC iYjQ== X-Forwarded-Encrypted: i=1; AJvYcCVDcSJyfwQks0WvvChxTNjnr5OCbylmHTAfLZh7qO8X06S30+HGsA4QVzJ4ok4+phHglNiWnmRaBwUEwMEClExPpaM= X-Gm-Message-State: AOJu0YzTzc8YQ2T38tUKjP18ooYZKy4nKT1XJ737ezterdKPSTYhgmRv KCEDqgs+37J8ZBU90xJ75Lcn6JIrCzQGZwQurSsLoNghvkYwj6PllFZmyhnvnt7eT2rOV7R66eq b68A52OJR4CRbZsja/nzwBC+MOJE= X-Google-Smtp-Source: AGHT+IE4A4/rfIGsWG7h/GFLk7I52t/+PtQ1YnklxECswLZ63Y7dCMMBteobGf6eFHtUrClt1pRtRRtwA0W49WQ+RnU= X-Received: by 2002:a05:6122:3c83:b0:4ef:58c8:4777 with SMTP id 71dfb90a1353d-4f6b849f989mr451732e0c.4.1721815127606; Wed, 24 Jul 2024 02:58:47 -0700 (PDT) MIME-Version: 1.0 References: <20240724085544.299090-1-21cnbao@gmail.com> <20240724085544.299090-6-21cnbao@gmail.com> <68ee812b-3b96-4c8b-9a54-70d4742488bb@suse.cz> In-Reply-To: <68ee812b-3b96-4c8b-9a54-70d4742488bb@suse.cz> From: Barry Song <21cnbao@gmail.com> Date: Wed, 24 Jul 2024 21:58:36 +1200 Message-ID: Subject: Re: [PATCH RFC 5/5] non-mm: discourage the usage of __GFP_NOFAIL and encourage GFP_NOFAIL To: Vlastimil Babka Cc: akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hch@infradead.org, iamjoonsoo.kim@lge.com, lstoakes@gmail.com, mhocko@suse.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, virtualization@lists.linux.dev, hailong.liu@oppo.com, torvalds@linux-foundation.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 99D1120023 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 98if9sp3t5ikb69msczt4aihzc7hkbwu X-HE-Tag: 1721815128-536670 X-HE-Meta: U2FsdGVkX1/o8sOWpq41w5CxBcJvLLdTxZOebuiyEQ6LlDJjG59hDqJXFoDfvX1iok+2f1k0atHuBYQOWAYXDximBPkXifjeyqiSo92QS98IoUOjX3FGrqERJKWHQ4ySliEDgcUi9ZipjJ2QzUMO6XbXOYR6SQgfOjlvzBlb1l8wv8dx16R+15HsLXcqdagnayUa6pZ7sek9GEqgw5g+kPCja7DQOR8O49qWIAeZPIijL+rvnkBvkcgJ1pKbLo5faEPuWIznYj3C+QKCAbwrrLLo+xqqO5ypuh0nDpqM1IgFDZwP0vTeQP+FW0ZQxZNezbqCvKiL9B9WGe3XRHPM6iQ8MYMTm8qaAREJMsjbb45H/kzWWWvpxStPecJ+c0Fo8BCIPxcpcln/PFK7bCBDclieawE2jtV8FxWcoFAr04XqjbNSbm2rJ4xxSvqaZcKw/yI65KDEkvwGpj95u3NRzAaNraVsizYUX2RUDCmEf08+tzRo9YiwJKsFJR+JVBkxVBNrZtc+Q5noSNOIJ02ZhHfqnFhhjkS3FEgxAZg4iGThgz7nlPqJBlQanRBo6xwXUgTwO5RJqdUNAN3xboO4hHoRmx6QjZNh0lLcuO20Vt6Jfc86B2WJbQyyIKtWMfx0WWVENBZvLiVDriKtLNHAh1Hg9VfSo7O36kUxBN0ai8c4/mC2gdWfyr8gOnX8xOW1KB1w7rpk+QfCTxztmiLWFVk+r/SLdSMo73puI+FOMD2kbFLtZG76ZPHWNz2HND5MmcxX7zuc7yD4F/GT/GEBabyVhUHrsctfIV/BQFa70vcmVZzBLd8sd6KdvOU/HOeUQPjIRftrSqQP/2H3f3cCMoklwAkGq2SAyDheNfVR1eOjOfYf6mGjUkwe11Di+BT3KoiECGExLFCDxhaMpNrp1ekHNq72++XUx1QY+uu6fpEymx2it4nGQ+j+DfQ97LBiy1lvgKgT+WPj42CVsOQ 7rmJGC80 AYsvun5vzfFCUgpqL3qoiudatK3tKiSsmg5KDrpDmgcvSnsrzTSsQqq3E/I4Z9eqIMXs6rEggcvMaD7OA321jl2YF+7FMQPw/Lo0lF/mQ+KRumeL4J8VFK6JGH+KzTDZnMxq3EWN6RXN9PGjckR/x+b36F56WUUM8Ri8Nd/oUULsf1w28GBvo2U7wpBXfgrnXcQqh/ieQ+5fdM/h7wIRk1wB/EUhmpsrlS6HWYNyqXi2CuQm/AEXxEb+7X/bdvLpoIsid2zTH9dYRo6zSZd7nfkgVWPRUWAs5S/kaKqtu+9Ms7dM18kGwJ/azrdd2aMMh69tsS9gATdzkBFoz4umyDej8Bw+B9J9qI8ZuN+sgmAmoO3ZusCApiqVCDRP/gwH7194fq2FrdH5Ajkr/JPaKPpbSun2+MLyeP8m63iQOJn5QhXoX0SBb4pI02/5C83LuKoBSlDYTSSSKSbgvuPM9UGYkle830ztWwhHi 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: List-Subscribe: List-Unsubscribe: On Wed, Jul 24, 2024 at 9:53=E2=80=AFPM Vlastimil Babka wr= ote: > > On 7/24/24 10:55 AM, Barry Song wrote: > > From: Barry Song > > > > GFP_NOFAIL includes the meaning of block and direct reclamation, which > > is essential for a true no-fail allocation. We are gradually starting > > to enforce this block semantics to prevent the potential misuse of > > __GFP_NOFAIL in atomic contexts in the future. > > > > A typical example of incorrect usage is in VDPA, where GFP_ATOMIC > > and __GFP_NOFAIL are used together. > > > > [RFC]: This patch seems quite large; I don't mind splitting it into > > multiple patches for different subsystems after patches 1 ~ 4 have > > been applied. > > > > Signed-off-by: Barry Song > > > > diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xi= ve/common.c > > index fa01818c1972..29eaf8b84b52 100644 > > --- a/arch/powerpc/sysdev/xive/common.c > > +++ b/arch/powerpc/sysdev/xive/common.c > > @@ -1146,7 +1146,7 @@ static int __init xive_init_ipis(void) > > if (!ipi_domain) > > goto out_free_fwnode; > > > > - xive_ipis =3D kcalloc(nr_node_ids, sizeof(*xive_ipis), GFP_KERNEL= | __GFP_NOFAIL); > > + xive_ipis =3D kcalloc(nr_node_ids, sizeof(*xive_ipis), GFP_KERNEL= | GFP_NOFAIL); > > This (and others) doesn't look great. Normally there's just one GFP_MAIN > that combines several commonly used together flags internally, with possi= bly > some | __GFP_EXTRA addition for less common modifications. Now you're > combining two GFP_MAIN's and that's just confusing. This is true, but I assume this won't incur overhead at runtime since the compiler resolves GFP_KERNEL | GFP_NOFAIL at compile-time. Only readers might find some bits are duplicated OR twice? > > So if we want to go this way, you'd need e.g. > > GFP_KERNEL_NOFAIL which is GFP_KERNEL | __GFP_NOFAIL I actually considered this, but it doesn't always work because we have many cases: variable |=3D __GFP_NOFAIL. > > And probably also GFP_NOFS_NOFAIL and GFP_NOIO_NOFAIL (sigh). > > > if (!xive_ipis) > > goto out_free_domain; >