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 29619C3DA4A for ; Mon, 5 Aug 2024 07:49:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6781A6B007B; Mon, 5 Aug 2024 03:49:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 626A36B0082; Mon, 5 Aug 2024 03:49:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4EEC86B0085; Mon, 5 Aug 2024 03:49:12 -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 2F51F6B007B for ; Mon, 5 Aug 2024 03:49:12 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id AEA1E81D70 for ; Mon, 5 Aug 2024 07:49:11 +0000 (UTC) X-FDA: 82417416102.03.05274C3 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf14.hostedemail.com (Postfix) with ESMTP id B4590100008 for ; Mon, 5 Aug 2024 07:49:09 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=afYIZaj+; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722844100; a=rsa-sha256; cv=none; b=mo6l1I99CyOKBvzs0id9JRVOgNpL6Tdywjbkg+o6+35qOiWjO1a2bzcvE0pSiKEXcQ2o67 fOr0Pb95z1YggA2TTAJRQOaVxUQi1UlkOatdpRlsReJOr7VZ2ReGmVGYrNcDBzPLirweN8 wGrLANz5CA0HyQ5lisIOGo+vWdwtF/M= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=afYIZaj+; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722844100; 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=QqtCFJHZfxqjuoiQwN6L9m6lEWWbZo6e4mfJzb21QCo=; b=Wk+5OufrTekVY3pX5wYaW3R20gKA+J1Hm56bpRjZ5QlzQH48rKXVc2+3C3WqqMinhZ81aM +Hz2iY+anLUuNqgBRy2NaCnN95ECfN+vPP8DnYEON0j+C2IKmPtVFQRPjQfAUTW4kzJr0t lKQQen5HEXjkNj5RWuvgmeXg7ZnPFiA= Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-a7aac70e30dso360132366b.1 for ; Mon, 05 Aug 2024 00:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1722844148; x=1723448948; 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=QqtCFJHZfxqjuoiQwN6L9m6lEWWbZo6e4mfJzb21QCo=; b=afYIZaj+yEe4l3OFqP3QHUB3LBF7dSBijO6OqOlltFk0C+X103B0x9d7zmk8yAVxUU Wvsr/q/RdQ/Qq8194H2CG9MKIUcqmrFk8X3/WYUACdd7KzPF7KIRYhVDHZjb3YIGm76j AViv0ZVcvnGQVhq8MLTuvKXg9U3S+T8H7i2magtjRYPP11tnkxJv8RGLXdNNv0x5iakk bfsd/MraCJ9cQwLXuqAWMTTtS3KIcEHVdXbCSVDH625pVg2MtWKteLhze+K8+qhdnck4 qzHUba/hoylwv0Gw80+ORINqYaQnXdG2bgd8I9PWUxvUHi5qWswQIMFrFpSnKS2OJMXV FUOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722844148; x=1723448948; 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=QqtCFJHZfxqjuoiQwN6L9m6lEWWbZo6e4mfJzb21QCo=; b=oE5zzL4Y/j4vN8OsuozBYxv860IjIY2H8mml8WQ52sks0CeJu4wstNt5MyaEYS80Fw 1CewLOWZySmGOFdhNbWonlAd34ETaXZ6qPbyxyrqkgTf98n0VM6nDzc4nEsgwiKO9ZRu wEdeiiIlmVUy/G+yn8cxjFVPEOqJGe96vPMDmSTsRGy/LpaTFlGGZg8Vd6bRyYJ6atUO 10Pdj1J3rea+JqmfNLzdVFGXg6LBMogKyk+1BnXGIWYB+LgV42fENQJBjm9tFwHpYIZ6 EsoZ16rfSgk7Ro+8/p8wZPM0MAfVgFd/0RTaGd1P17DdJmY0cKOxRvWlpzKGsENzfVpx ftLA== X-Forwarded-Encrypted: i=1; AJvYcCUv224c+Fl9VwGWyk/SOIUV2i/ZLX3VGjORAmdmN8+tRT9Tq1FBqUCzBMuRb9A6xx3XLkiAwbSq670AlH7wqbHroBE= X-Gm-Message-State: AOJu0Yx+RtevCxAbZ6Yj99Y0Zxm9LhXY/ZSm967d9jvmJHx9a2gf4GgW ItcLaxKXKRqgFfdAHKuqgC2MHCl3VlCZ7W9fdpp8prR1mpS4uIrJd8JS9Jfwuso= X-Google-Smtp-Source: AGHT+IFu7JUzbPPWsUCf+S7g+aZkSaH2v5evE4d3+S4cYsPWK0lpIiuHybfx4lO+A8DgucpZYEc4aA== X-Received: by 2002:a17:907:6d17:b0:a77:de2a:af00 with SMTP id a640c23a62f3a-a7dc5179808mr899865966b.44.1722844147758; Mon, 05 Aug 2024 00:49:07 -0700 (PDT) Received: from localhost (109-81-94-215.rct.o2.cz. [109.81.94.215]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7dc9c0c0e0sm421128866b.67.2024.08.05.00.49.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Aug 2024 00:49:07 -0700 (PDT) Date: Mon, 5 Aug 2024 09:49:06 +0200 From: Michal Hocko To: Davidlohr Bueso Cc: Barry Song <21cnbao@gmail.com>, 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, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, 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> <3mevqjzu2emxd2f3zkrurnzcal67k4lpkcdqzfs75qhp4uflbn@skz6q5odetdr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3mevqjzu2emxd2f3zkrurnzcal67k4lpkcdqzfs75qhp4uflbn@skz6q5odetdr> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: B4590100008 X-Stat-Signature: phgbudguf15sd3irxzcnb41hsm3azpbh X-Rspam-User: X-HE-Tag: 1722844149-100488 X-HE-Meta: U2FsdGVkX19suDFdK2kEEmLCcm2ZLeyg0BW6IB+VorwNpG/Bd83Di/n6lVlpqYu/IoP+tsxuAglpbWnymfFVaRiMvwenMjsyYKcstSr+3Cz0aVt4Vwg9+WtBzmQv7iHXV0JbeNVRFmCnwOxwZ+FMmyxSnYjdGSvb+VOFQl/D/K7dIYrIbw3xKf4bClCMM4ater84JbAJmxf04hq8crOhUTcgUgysBbiBWwYaagK3B62TDb0gq1YzIhXRsmjGLvod0z9eaeCn6ifPBvDGAwNkNOwjj/PTqpX6rN7U1ydpFI0Qu0b9pioIDkVk0zoTLgDqnK1qGShTvRNcXjnn00+01nsxqzjNMsVUzGB5d0VonLNZ1EJJ6Vz8cdWRnewXCD+RVA0M65J+KW4IUWceihg43jrPudgKDF9dE4Qdymwts3XWABXCybHOIZJspPElCF+0UUVVU/RSbgIrHITROhcaQ33QhmaIYIcSG+JHWwmz3PKes6v4jGj7SB6awZsUdk59UGa2sxxr8lGdwgka5Wky/KyNVFCos9HXi957thQgREypuXv1GhOnh3Jmx9sT5K4XWtiWVok463NFk6eyllWBTjdPxyjO63seVlhMIJjupdDAN81lvxujeEN279nzKBYOFmpr+ymYv7pA4Wq2oLiwhlCzD1bHKNpKOUXZUI6zaybeJolgYnp9VWj/vMZtWpz3ClBT4UhSI9PThlewpTqN6SXbce4d+Pg69SG7jy+K0ihszYOeJYeXtBS69Zj4KnGhOgRKYtzhKij1Go8bccqFvAih/E/vMN1SN3feclOZAZYmabNcvqD2kY2sxj9m1BjLjgk8GHPqcFM/RBzlO4SBGnCh+W8iVMkHUbanPXbqROs6HKvpUlD4fF+tP8zyxzmVMTnd4+1Yh1F0ru7FAqUtF6BFgJRLZmB7xwslR79g9IQL+g/cFP5NZYNehbnAIXTKfyL1WvJdNEbXG5+m6Jv RwOQXP3I F604x8iyoyxnWs7FXRGfL28PQy17DPKHEGGgbqB33sslEkwI1iz/Un1rUYRTYiWHqJ125/SfWVqFFYpYLB7NZRIpWzerTGtmg0ZZvJ7mKiTI0sSUaNRXkfiP2rCLinM6StD737Gf2kcwt/Idj9BoWvZiOLpm1baTRJF1OJLS2NsA8QVAmwsN062LaiiTLYyCuEUXWYKvYw6J38tQuZ0z5VOySctb2BtY26llwlpS8N5yA+H6LI1Phb00vz7kuKHPQLv6mqxk38whpyh/mB+TdX1QPxffgNSonTYoolBvqtlk/dl1cQ9C0jvLPm8013OGYLoWee5qTOxtnYnN/WHU8AIsCGXWVVitCO4Yd/MdWG/uRdTYKIRkiKBT33Lkohcj3T7Lhg68nqA9SiVW6PFS5kkmKYQ== 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 Sat 03-08-24 15:15:56, Davidlohr Bueso wrote: > On Mon, 29 Jul 2024, Michal Hocko wrote: > > Because it is really hard to figure out what it is supposed to mean. > > If the caller uses __GFP_NOFAIL then it is (should be) impossible and if > > NOFAIL is not used then why does it need to check for > > (gfp & ~__GFP_NOFAIL) != GFP_KERNEL? > > Agreed, this is pointless - and cannot recall why it was justified to have > in the first place. > > But I think we should revert back to the original check then, which is there > to distinguish failure cases between normal (GFP_KERNEL) and nested (GFP_ATOMIC) > contexts. Removing the check altogether would change the fallback for regular > allocations. > > So this would be: > > - if (tbl == NULL && (gfp & ~__GFP_NOFAIL) != GFP_KERNEL) { > + if (tbl == NULL && gfp != GFP_KERNEL) { If you want to tell between sleeping and atomic allocations then already mentioned gfpflags_allow_blocking would be more readable IMHO but the above is much better already. -- Michal Hocko SUSE Labs