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 7F6B7C3DA61 for ; Wed, 24 Jul 2024 13:47:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F00BF6B0082; Wed, 24 Jul 2024 09:47:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB0A86B0085; Wed, 24 Jul 2024 09:47:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D78A96B0088; Wed, 24 Jul 2024 09:47:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B99636B0082 for ; Wed, 24 Jul 2024 09:47:55 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2345A4092F for ; Wed, 24 Jul 2024 13:47:55 +0000 (UTC) X-FDA: 82374774510.02.0C5ACCF Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf16.hostedemail.com (Postfix) with ESMTP id 0620B180004 for ; Wed, 24 Jul 2024 13:47:52 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=CSlE9qhx; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721828849; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=woGjJUalBG5RmmZBOtkde/fWyxqIWN1lZPYfjOI7zrw=; b=jsMiuaO7ElpajChcpy0F3RE32ODkE+FENHv3AZWa9LjnY4/HpsaUqM5hqvCQv2Z7LpcjsP OwfJmjqUW1lNkmTtbK5FKbdy1UGKo+s3pCvxb1PLZtNWwj8n7rDQXP5+7g+lRDJqQ60g9R Po2Y0ukRrkkHoHpyqOvXpRPI9RbnH78= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=CSlE9qhx; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721828849; a=rsa-sha256; cv=none; b=XVDgLK1eal0l6oJgG5yZoSnwC3rBZhCZK4qFiRWd3u7SdgJLPlIj38vkJfz3zKoBKTnkyw fkW3O/qIXNG3ayeS/fZeP+7c7k97dRen/pw85wrkyJGtnqsGmU4RFy8OVe9FiKwDaObG04 5lq+y+tfwbiDkMeBe/yBtCYfbuDDaQs= Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-52efc60a6e6so6198243e87.1 for ; Wed, 24 Jul 2024 06:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721828871; x=1722433671; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=woGjJUalBG5RmmZBOtkde/fWyxqIWN1lZPYfjOI7zrw=; b=CSlE9qhxjXaBT/BUx4ld9f4ziDfVaD+RgWmOG/+/BE/e/QqcmAXOBBDyhoo7OEbJjM jftnBMCcM7/6HoVJQWzowli0tk4vwLo+lGZchg1MwAj34u/hTwikScAeOJ4Z6F/DgI1g Rkt4OOaeKfn7xGFp8OidAIhODrB9wcoMqNbKpJhRHjgKn0/szLvirC0FHLEiM3XciYcD GaxkvA61RLf4GpxKo3KL8I/3PY5C6u2ngnURdil+NCfnfhKfxUdZ0zgbvm6/hbTlw+eH E1hMoRoAz+tqmkUEGw1I5CM1PmrhLszT3VKUfQREvszCnmjz4JVgSZDE0W20NDQyFf9a Df/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721828871; x=1722433671; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=woGjJUalBG5RmmZBOtkde/fWyxqIWN1lZPYfjOI7zrw=; b=SjxqNHh+KGR28lE0Wu9ptxM9VtKu91ZyMXdZQ2k5DQl2l5XC+vnSJfFYyv5ydzIaNp /p+ev6ejqnLVD3a76x1PkYxfIOHoRU2VnYA7yaaOAF+pq0nm3VEJ4lmyFSifij7KAZqE twdQmp6YXsTK95liDLPLZl00BUnJz9q1cDwM80noelV8xz3Dk0JtZg3mGCl5Lmw2rrN7 z1CMRWJpECWjyR/BiGMYEurR2uqOrNL0u9q6ZZ9I8jcJOrsRvki6T3aAQCiee0/aFVWO Re4VKUvUQdAqAFbKWsKYhSzR2i2Ek2pMKpThvGde/9d+8d1mWC7e7ZQYhipNanc8EH5V 8MrQ== X-Forwarded-Encrypted: i=1; AJvYcCUl4LVEJEmzdyagDEGHsOL/08fXNZb/AftwoPOAD4ta4PnfJTkc4SZWyEhxD4APGf9RfZDD2A+SKukKEF54MsCuihg= X-Gm-Message-State: AOJu0YwjnAtPCZn9C8TcnR0uPFvppP5ixY6lv/jYQ0oIUhqkNfcDa3U7 /pmgGaFemTQ1G1zHanRZTpbXbfIq9X5g5P9e2+eOubI7oaliYXShoMn+dUDn13w= X-Google-Smtp-Source: AGHT+IEm6r8MW3jAPa7enMwFdgbk5R91xq+SdGgS0mNQ6bgCnTIaUWtpBNZV5D+vrvTPvOV+lAaDYg== X-Received: by 2002:a05:6512:39cd:b0:52d:582e:8093 with SMTP id 2adb3069b0e04-52fcda2626emr2018789e87.23.1721828867923; Wed, 24 Jul 2024 06:47:47 -0700 (PDT) Received: from localhost (109-81-94-157.rct.o2.cz. [109.81.94.157]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7aabd8cae5sm91255666b.146.2024.07.24.06.47.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jul 2024 06:47:47 -0700 (PDT) Date: Wed, 24 Jul 2024 15:47:46 +0200 From: Michal Hocko To: Christoph Hellwig Cc: Vlastimil Babka , Barry Song <21cnbao@gmail.com>, 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 Subject: Re: [PATCH RFC 5/5] non-mm: discourage the usage of __GFP_NOFAIL and encourage GFP_NOFAIL Message-ID: References: <20240724085544.299090-1-21cnbao@gmail.com> <20240724085544.299090-6-21cnbao@gmail.com> <68ee812b-3b96-4c8b-9a54-70d4742488bb@suse.cz> <400b2f6f-f7f0-4888-99ee-7327faad7e5c@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 0620B180004 X-Stat-Signature: wokerh3igzoewkz4dfkxo83x9ty5zunm X-HE-Tag: 1721828872-161815 X-HE-Meta: U2FsdGVkX1/8DZmVQTh6QemtCe1pPDfGsz/c0YoW2wTTLB0v9jUM8KZpW07dnv1ay6szXk1sdXONTi/L96j/5iYA5EPvdsC2aikWeK795G8fY6mxf0QFKng9AFjviX7UBiWArEyY7g3yD2FfhtBm5++ceSXPHqwIWmWb1cfKYEphsI74XNivH1GiQ9zej4lvPmt7cW32vMElHx4FGH3Hc2zROuwPJt4Xpykt94neOKd6breJ+ZJaZAsz7ep6y7eppIQlJMfp+jKpLkhpzxnkaHa8aef0elotkdMluMh6cUBFig5Y93GUUsv9RFZJ2ArBkBpi+DlL4vPF1+nDbFvhQploVJ0L2GS/Lm7dEwqgJXDeEvKlkayh2BfFpfzWud7AmjPN0AcqJRuagLMSSS44DwK3xW2pZHXBHsvgquyorcxffGJ2ufXBJSs3Ry29+x/d3FvVUFFchoycGEj4813FjnHf91dA9OmbH6HZBvxPdOhsEhucnGhT6LqrKDwRBZDXTMza6l4biA4EyeuaqEKqOhEYgKg1i2fhNFqKEQaov6obwMANuZe9jns38g6fimFz12Id6oN3ew3bpkpD/S5M6ScdnMgCtNoSTwjcDeYiYrGcbzyQEeaD6b2IxYF5TaA61AxlhQ8AVT3II/wdoJZKez/OaqDJGxsCBW9JWTzDIk3VTnZr/zZ6H7YIqiKIWTjdv87JyExE0LP9iTf8etOEubC22eJhDzMQ8lgv+33XKyrT1Vl9zn+eOXv8YKSMTz/ClBQTiyk+QEwP/YQlcUI9g4GrumNR87wAGf/bgXVrVYM+tAR9ecCBIBeEtv/TmNZw0XeYa/qC/Z5clJe0rNevVG+/yA4KrQdFjavn3nAwWzQaIR/TGkYqd7Blbh33LVJZqFSxO4VO3Zxqacgf52DGkAPjuqUxnINC56jmdJqYjiZcrwtjOZF/74AAdGZFjioPo8fPT7zw33X1t5kgop5 msSTxb3s fy73qCp+r/+H3HRjJ7QYgDZeUlyCi0gGxCJFQlvlfe+xyxhk1ivtv/aa5GCAH+53XkKSbQLplaOs3jBBUCFDBXmrfNty06whpgk0T+fGMlP03rz7AgVHeKAIYl04vii+X5R4OFkHxUWRNnMp8BvcPksuVAUIm+DE6SAoC7oKx3H9ldbHS3SMF7PMFmg4KgAxDVK3pDQI67sDIB8zUCPnY7sQwNr9L7tXu4F6u2bCS1LAE9uib+UPSkmN03fj3birYiRC35PR4nJrkAT4G5+G8Ns/wlExiDfiWjnlhaM8RvfQm3S6VIcdR03ZAvpYrLuq4Z+XbJ25sriiKn3RCagdXUDAflWWX3xuhx+TmhYmFaM/9wtu33u5VCDNnH3TwQTZvR5KiebP9hzrGdX8TRTAows62Lg== 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 24-07-24 06:38:41, Christoph Hellwig wrote: > On Wed, Jul 24, 2024 at 03:33:19PM +0200, Vlastimil Babka wrote: > > > I do not see this a problem. There is no real reason to have a NOWAIT > > > allocation down the stack that has a different fallback strategy. > > > I am not saying that this is the current practice because I do not know > > > that but I am saying that this is not impossible to imagine and it makes > > > scoped NOFAIL context subtle and error prone. > > > > I don't think Christoph proposed scoped NOFAIL, just use scoped NOFS/NOIO > > together with GFP_KERNEL_NOFAIL intead of introducing GFP_NOFS_NOFAIL. > > Yes, exactly. > > And I didn't think Michal thought I meant something different, maybe > that's why it felt really confusing. 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. Thanks for the clarification. -- Michal Hocko SUSE Labs