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 C42C3C3DA4A for ; Mon, 29 Jul 2024 10:16:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F4F06B007B; Mon, 29 Jul 2024 06:16:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A7AC6B0083; Mon, 29 Jul 2024 06:16:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E87986B0085; Mon, 29 Jul 2024 06:16:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C9A8A6B007B for ; Mon, 29 Jul 2024 06:16:42 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2F5EC80273 for ; Mon, 29 Jul 2024 10:16:42 +0000 (UTC) X-FDA: 82392386244.22.29A2E64 Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com [209.85.222.42]) by imf23.hostedemail.com (Postfix) with ESMTP id 6380B140016 for ; Mon, 29 Jul 2024 10:16:39 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=H5CosTSZ; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.42 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722248146; 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=jCS5MZ9r7gw+RMGRX5IylR1ridcEpqKYpUMo9Tzh9pg=; b=NZLg6TReXZIb+PAVrxBWFBv+yi1JJKIcWtnEBSIqvCNBmgFpcuovOh3+fLvSDfHsg6I2LZ T6RqN6ydnkwVrKpK+Vd1Wzve8HyHf9A1JBnP2OFK+kALgzao1LslQPkJkoZYZv9ycJ9ICr Li727XBWkwkpV6sYnwyiW3E9KY+O4gc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722248146; a=rsa-sha256; cv=none; b=ZnhtkTyolIUsr6GISRFoURpXbHSsPaE6elqEj2FlW0EVmnT6q8iZQyXYOyML6iTgndeFdJ AXcrOKfP401G1qdU1dmQEVQbwVV9f5DFu1HIZY9/9xRTEFTeDJ6pAVezoBQgKfU6hXO/Rk pm2OOrE9ZYQScPYTevJjxbIX4oeNM8s= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=H5CosTSZ; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.42 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ua1-f42.google.com with SMTP id a1e0cc1a2514c-822cf222888so806234241.1 for ; Mon, 29 Jul 2024 03:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722248198; x=1722852998; 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=jCS5MZ9r7gw+RMGRX5IylR1ridcEpqKYpUMo9Tzh9pg=; b=H5CosTSZGIi9cA3JS+0tzVY6j/7g7ljoDihDKhXyMfvy+GjTzfvrLGTXy4buLPusQe TXTanIv22oVIhPCoLAsRteGZ6KP+BmbpOtfdQ5OMwJCW752Lz7onfQx7UgdEmpsBOgK+ cf7Apvn2VsRgiGjpvNCTrc6zvchxRmu5NzpyUVsXxAfUI8/2SW6DIWKfOwDehDms+1iy gKhUM/FStlRMtTM377chAH4Adg0biuDM1RyC5QUJ9wl2WwzI5SkSAdJPPbQ3nnDd/F0Z k4wU2MWeHlQnk7h9zXDCHwrgBkfpo7FFQevw0CW1VXKvyI8CtnWoETIxiLUvU29m5ts/ HHrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722248198; x=1722852998; 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=jCS5MZ9r7gw+RMGRX5IylR1ridcEpqKYpUMo9Tzh9pg=; b=aQ5k6u5zASDJIsEE8Zp5hpbEtDZoPgrva88TL2z/lWnleIKntZIjhTGr+JIwgPPm8M wWN7SN4VHiXzKNvj9vVxVZKpL7rG8SwyxAeER4v6vBgmHes/zbL370IqEmTTHKv8r3s9 ghkPRrxPvBFcUKfS86VmdsQ5gH0zwUnUHizLwkLBHB5fmgkV6UIf193Q+YFZIfk909xW qXg5r4TfWlnXtSqcTHPHbo0JdFfBlIp0ieMroIFRcDQuz32buDLqOUn9+JjDZuu66Z98 S37H0pjQxH65EgMzq/IFTKU3d3Ux1WzGNmJ9i9ptZr32yM5zRlAjkUnS8jES0wPZZDwh m9pw== X-Forwarded-Encrypted: i=1; AJvYcCUGhf2O2l0qrjwKRQK3pxUf8fFe7uPkdZbEVoYQvlivpK/UbCJHfcNiO9ANTUWC4JSy5mtss2qqo8evagfqbabP9vQ= X-Gm-Message-State: AOJu0Yyd4gHmB5tjj9THOZsb9oafsdPHWTq6mSvCyardsJQcc14RbdTq UQT7+QZOvl1yWfzTnGWJRdAI0N4ATb0WFGON9y4mFWU4P+hgL/of0oc/u6qbwaRtSAl4E8kxCyJ LL5xBU+nPr3gorZ4rIE+iKmoH9V0= X-Google-Smtp-Source: AGHT+IF3wvNZe/9pf1Jf7y57v3ZTKTnPux2CX/AUvAurW3DozhKpEMRZkQbAJ+R5o9gAelP5N8894vkHGHuPzM772AA= X-Received: by 2002:a05:6102:2ac2:b0:493:cb14:ba15 with SMTP id ada2fe7eead31-493fa1c9195mr8813445137.16.1722248198265; Mon, 29 Jul 2024 03:16:38 -0700 (PDT) MIME-Version: 1.0 References: <68ee812b-3b96-4c8b-9a54-70d4742488bb@suse.cz> <400b2f6f-f7f0-4888-99ee-7327faad7e5c@suse.cz> <5b9fa06a-bcef-447c-899b-fe3fb10315bf@suse.cz> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 29 Jul 2024 22:16:27 +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: Christoph Hellwig , Michal Hocko , akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, iamjoonsoo.kim@lge.com, lstoakes@gmail.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-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6380B140016 X-Stat-Signature: kyafntus935ig5p4kjdrym1e5qd346z3 X-HE-Tag: 1722248199-211695 X-HE-Meta: U2FsdGVkX1+kKEcQsCRHkqWdOm6wC5MkwsBW7dPS8sEG6p2NDEuAXTqh5Z5rSf055/8bhrMGwByClXPxtHYHx4SYiVhafeDwOXHwwuCkcawwc3+XGK6uoUXRpBBYw+bwWQI5OJ0bgtKtsgQhklhaU8PZ0XeVfW11ik1S0D1GpbhmyfcQb3uOXJkAI8IsijPUBRiC9CeK2+G8oje7AAS3Dy98N4NE92rwIhDA2dxRWU1mfe2pLzJ3UTRZfRYq5sei3PRKxTRQvaFGkv3dfAQJZSKrl2AIY8URne7AoTemXZ5oLRtYmWKHcHNmkL5RZcXZEIE2uZv1mfdoKCdTIU69k7n3pkaLarIXtbSZ5jRSOksderz7HLy0zzQ3GfTmrX/lI9ebvQZiHOPjCPbkVuxBXbbB0rJei74FRdBwkJ6ZgTLX3Fsb9eOvNCfI2XqdICGbk8GI24lSUoOev+GrR+l2OUMO8xVTr29ZwJxTSpf7ypHFoOov4y1Nlll0bLt+z5FHU8C4uh4/0NDsdUh5/ILptQY299yu8hSElljhHtKRCO+d8cC/1NPRv7xY7/TUWT2kYqRuJMQXNY2P8IQLbiHTRIjtXAw1QSPnINS+wDW9Jb4A6PXYFq1DHoQv5k+D3LT/+2wQ2sOUS1NWaJeCjzWWDU9Er3jwq/Ao/DWfUAPGGDXJCKXOqpgLy0f95BvE40or0cCXAsOUCgYvNbQOg3I4RGE8Jtu5QF5wZp6m0esgsxjNR8qjuyacgG7HgQvnY5jG5IBytjRMAde2/hWGzurHOX6QdcycbQau6Fjk2xhUmMD9kHx5iozCS98SYeY/Zs+td/Qx2x9vjtzYxMERVWuzqVC8YmeIxfJVWzXC68rEi9TaSxLLp0iOBI5U/3wMO+pbj8za+S+eFphmqHMLkiTdaRqSZ1PjxsCwxv9sOc8v/qqjj565/i7zqBh6ViLsVnlW6B9+Cvbgsiviqp2oRCR 7TpN5La6 /S2tjX3QosxFz6hKRcZMsEzSQ0Ry3PKiGNUcRz+JbS+Bg1sOHXU44eBL9M9pjGto2lCkrKxJx+kETs/9IdBnCJWJEBqVEN/zUEMzSmME3kX8CvTv0s3eU94FCLs8A+NhZXaIb1wuhJP0mci6CVCDnFK0xlREV+Pv94ph1CWTpHLS6ZD0svrXud3hQ0EEPJjIMzfeS2OxLx+FzkaMOOt7I4YVP1Gjq2rj11XyoiOhEz97pxt16rkqlmUKfNBXHmqQSh9732AgRWC1y8VTUMUvAl4kiYj+/ujppk0oT8E5qmshaAnKuPFXC9MNXGiCR6WDSujH00X4xY0Xt32jwor+g5x5JHuaVvFEiKfNK9iYP63lrvLGRQNliluIjm6cenqTItQypBoqPhgwS+cMBhAiLQJE8PKL1SKAqHmLPDNihwW93hON0LVmN28nlWtvZHCg5l0Y9z9NY5sVYsga0Rz3QM1qo0WJoTxvt53k6pO8vvoHoDEDeOmGfc3frqA== 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 Mon, Jul 29, 2024 at 10:03=E2=80=AFPM Vlastimil Babka w= rote: > > On 7/29/24 11:56 AM, Barry Song wrote: > > On Thu, Jul 25, 2024 at 1:47=E2=80=AFPM Barry Song <21cnbao@gmail.com> = wrote: > >> > >> On Thu, Jul 25, 2024 at 2:41=E2=80=AFAM Christoph Hellwig wrote: > >> > > >> > On Wed, Jul 24, 2024 at 04:39:11PM +0200, Vlastimil Babka wrote: > >> > > On 7/24/24 3:55 PM, Christoph Hellwig wrote: > >> > > > On Wed, Jul 24, 2024 at 03:47:46PM +0200, Michal Hocko wrote: > >> > > >> OK, now it makes more sense ;) I have absolutely no objections = to > >> > > >> prefering scoped NO{FS,IO} interfaces of course. And that would= indeed > >> > > >> eliminate a need for defining GFP_NO{FS,IO}_NOFAIL alternatives= . > >> > > > > >> > > > Yes. My proposal would be: > >> > > > > >> > > > GFP_NOFAIL without any modifiers it the only valid nofail API. > >> > > > >> > > Where GFP_NOFAIL is GFP_KERNEL | __GFP_NOFAIL (and not the more li= mited one > >> > > as defined in patch 4/5). > >> > > >> > Yes. > >> > > >> > > > File systems / drivers can combine =D1=96t with the scoped nofs/= noio if > >> > > > needed. > >> > > > >> > > Sounds good, how quickly we can convert existing __GFP_NOFAIL user= s remains > >> > > to be seen... > >> > > >> > I took a quick look at the file system ones and they look pretty eas= y. I > >> > think it would be good to a quick scriped run for everything that do= es > >> > GFP_KERNEL | __GFP_NOFAIL right now, and then spend a little time on > >> > the rest. > > > > I assume you mean something as the below? > > This would work but looks too much like a workaround to fit with the new > rules without actually fulfiling the purpose of the scopes. I.e. it's > possible this allocation is in fact part of a larger NOIO scope that shou= ld > be marked accordingly, and not just wrap this single kmalloc. Absolutely agreed, but the scope needs to be determined on a case-by-case basis ? The module guys are probably the better people to set the appropria= te scope? It is difficult to assess this solely from the mm perspective. > > > diff --git a/drivers/md/dm-region-hash.c b/drivers/md/dm-region-hash.c > > index a4550975c27d..b90ef94b1a09 100644 > > --- a/drivers/md/dm-region-hash.c > > +++ b/drivers/md/dm-region-hash.c > > @@ -291,10 +291,13 @@ static void __rh_insert(struct dm_region_hash > > *rh, struct dm_region *reg) > > static struct dm_region *__rh_alloc(struct dm_region_hash *rh, region_= t region) > > { > > struct dm_region *reg, *nreg; > > + int orig_flags; > > > > nreg =3D mempool_alloc(&rh->region_pool, GFP_ATOMIC); > > + orig_flags =3D memalloc_noio_save(); > > if (unlikely(!nreg)) > > - nreg =3D kmalloc(sizeof(*nreg), GFP_NOIO | __GFP_NOFAIL= ); > > + nreg =3D kmalloc(sizeof(*nreg), GFP_NOFAIL); > > + memalloc_noio_restore(orig_flags); > > > > nreg->state =3D rh->log->type->in_sync(rh->log, region, 1) ? > > DM_RH_CLEAN : DM_RH_NOSYNC; > Thanks Barry