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 21EC6C3DA49 for ; Fri, 26 Jul 2024 21:08:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42BCC6B0085; Fri, 26 Jul 2024 17:08:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 38CD96B0089; Fri, 26 Jul 2024 17:08:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 206466B008A; Fri, 26 Jul 2024 17:08:30 -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 F3D906B0085 for ; Fri, 26 Jul 2024 17:08:29 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A0C0340116 for ; Fri, 26 Jul 2024 21:08:29 +0000 (UTC) X-FDA: 82383142338.02.A1FCBAC Received: from weasel.tulip.relay.mailchannels.net (weasel.tulip.relay.mailchannels.net [23.83.218.247]) by imf19.hostedemail.com (Postfix) with ESMTP id DA6B21A0013 for ; Fri, 26 Jul 2024 21:08:25 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=stgolabs.net header.s=dreamhost header.b=UxpEjF3b; spf=pass (imf19.hostedemail.com: domain of dave@stgolabs.net designates 23.83.218.247 as permitted sender) smtp.mailfrom=dave@stgolabs.net; dmarc=none; arc=pass ("mailchannels.net:s=arc-2022:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722028039; 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=C/UUV8Pwaly5m7expdcVhsl9qGLrZb+mf5zUcZao9m8=; b=hMU5GJZz8JCdq5Ml7Ygo3H1sUcs54j0Y9tfB+KRKTuNjdSX6FZ9Z8w0M7QCYB0KREf+SXN 0BE/BTOaaSixmKvZT4WfH1q9uD8VNh2VAF96+mrIELTQEe7NaKpD9Y6Br2nkmw4W5S8L6D V5TmmeGLIpyxlsDtvta1ky44kZGpD1U= ARC-Authentication-Results: i=2; imf19.hostedemail.com; dkim=pass header.d=stgolabs.net header.s=dreamhost header.b=UxpEjF3b; spf=pass (imf19.hostedemail.com: domain of dave@stgolabs.net designates 23.83.218.247 as permitted sender) smtp.mailfrom=dave@stgolabs.net; dmarc=none; arc=pass ("mailchannels.net:s=arc-2022:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1722028039; a=rsa-sha256; cv=pass; b=rYv0m68Cp+cxmVe0SY2UimQg7fv6uYMC58YuwYuYRqugCHYHZsnoqM1hoLtqlIu64MyAHj sQgOfBu2BJ3VV+yOntBfGhrGAEOK1zlmsgX+wyg7lkIRigC1wHTRC4wpX+hPCexsOP0EbT uJXYXJsYk80Lvf5oX6i1ivPHr+gznQo= X-Sender-Id: dreamhost|x-authsender|dave@stgolabs.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6BFFF144B92; Fri, 26 Jul 2024 21:08:24 +0000 (UTC) Received: from pdx1-sub0-mail-a312.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E8BB3144F2F; Fri, 26 Jul 2024 21:08:23 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1722028104; a=rsa-sha256; cv=none; b=LZTJwaPrgzQwwM2sgDw9QDGJPlX597wlfbbRl79c1EKzTfWITGbiMoW9/yJ4734k5NxOa7 iA69TdNd4fqrKZ6Ui0NYl5S9NhvQJHC6gzHMkA/BHl2vBIDVZG/QDwYalMVvLPxPFVdRD5 NjfntOYG7Gg5ifPv1PxoS5ipQW5W91Eony/eg+Dlu2oYTjchFOclhrHaH3IyaaLjSVhpl0 pf/hKMYW1cAi3bT6454qTxOHn/3e2dhmW2/MfTaBU+EEhYp9NKhIbUZwIwfjIrgHq2SITU 7LtvWncp9jH1dyOBnWp3AST0x98s1qYJcz1NtnQsb/maxtNlJGKuWpPyvbms5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1722028104; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=C/UUV8Pwaly5m7expdcVhsl9qGLrZb+mf5zUcZao9m8=; b=c3Qk7/K0kx1ypufDyZ52YVyHLe5t/aY3od8gFEPnqZcKlTrMHjThBYTk1aSSwYOfZr6Svb qks4mIhE//Poacpkv5/6PXD9Hv1h4ukMC9Ulm3lHyDkueV2dd89axaxr3lR3D8XJ6qZ8L3 BXzV/rczTaur6HzLssAcUPHts+cM+OlijWTnUKRpZP9PFHxmJ4d2lXVuD/QI35nw/laKOK IYjWei2rsB9ylqS4Av0vmq67EVGwqHm0izpRAk6fepCYpBylBh4iHlzUNheft7p1ozDpYe /PtQNpeQ1p6eY7GQWyOgZ186/UQqglzrGRPhQg02wi+XXU8x+arRm7KGEAxVJg== ARC-Authentication-Results: i=1; rspamd-7f77fccf7d-9ph87; auth=pass smtp.auth=dreamhost smtp.mailfrom=dave@stgolabs.net X-Sender-Id: dreamhost|x-authsender|dave@stgolabs.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|dave@stgolabs.net X-MailChannels-Auth-Id: dreamhost X-Fumbling-Harbor: 01b5a16b7727c345_1722028104322_804868711 X-MC-Loop-Signature: 1722028104322:3351102329 X-MC-Ingress-Time: 1722028104322 Received: from pdx1-sub0-mail-a312.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.109.163.137 (trex/7.0.2); Fri, 26 Jul 2024 21:08:24 +0000 Received: from offworld (unknown [172.56.179.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dave@stgolabs.net) by pdx1-sub0-mail-a312.dreamhost.com (Postfix) with ESMTPSA id 4WW0j23PdKz1q; Fri, 26 Jul 2024 14:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stgolabs.net; s=dreamhost; t=1722028103; bh=C/UUV8Pwaly5m7expdcVhsl9qGLrZb+mf5zUcZao9m8=; h=Date:From:To:Cc:Subject:Content-Type; b=UxpEjF3bCnY35+US8hdzYoksiVVUTQf5saY0UP8s0Iw2DAMEwidX0RCCKYlHruhhJ cxlEbiQ8/KspaFZF3sgLrp9N0OfVLMcuvywucJyk7yAxz9M0iXjtqjnxM1QvrOFa03 Xzz28M0kG0mXwqp+lddG5L1hUV2soEnQc+OM0h/ZBNqdffGSafhKdNVhmej9oRqMYd N2hpAvHkQVaG2+73O5gVTQSerfwjvnl7pG7qD655lT4Ptr9C2cL1L52XsfV0Fju4+j tBidCT2oetvRPLqTZVptlxBF01fp6mc00rWEeTg4+lFuj0WXbm4mbiTt0NEYpQF53p d/Q7wAMjWMYmg== Date: Fri, 26 Jul 2024 14:08:18 -0700 From: Davidlohr Bueso To: Michal Hocko 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: Mail-Followup-To: Michal Hocko , 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 References: <20240724085544.299090-1-21cnbao@gmail.com> <20240724085544.299090-6-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20240425 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: DA6B21A0013 X-Stat-Signature: ewx7grce7x3xm7eukq1qhjegcs5treyr X-Rspam-User: X-HE-Tag: 1722028105-393551 X-HE-Meta: U2FsdGVkX1+lmcEaqvCulCHWPlPlVyBn4vlsvuSq/EehpuGYmjq53f+OlVZ9eKN84s7bk+AgH73V0Jwe/heQSXBUSJnt5wP38Qrmhy4uhDC6c0QDFHPYRujpz2NN8YU4g8xFR1d9PiYqhjv9cbDD6D7bIn+tKZKRyKfSoRSi7cAKkcQSKiKJYJ/KSrsUCytgpIyhGmsa62f1r+WIVvJP/BtCWL7pDcJMLoAbPJebxFPnljYugNMdV1tpOuyX3VrMWzwaTXl2eQ6XBBdTUYe1/uuGm7pnqOJxai5SJYS5/yU+nuXNDp/I0dENTl63n0kIfA8pFOeGNEsRh9lm5AigzOOVp9S5XtnH0cOqcdslPoC1zav6SligO7k4eTPLmfff8HM667vk4T2Eg0NDPErjbzAUM8bvkU7tu70LFR8i+vbF3h8CrvMyVgJwyimdiV/S9Y6khYp/ZVBmSwnAq3BzqaKjBTSxoH48wfxP2ozMQDx1VJt3X0sWpQ/HZZNZU7mL8fPHhCs90drqZJDzDd2+VSzlgsYp8+VZXUpezwA12rca+sjt7wWNE4L/klgbvfGr2NK5O6gFlP3UQI6iUPvcutVx/5VD2ggzNmJJ9mWoETZlFMd8OfM+ehTrCC1pH1NexU5ahhNm4/hMV9hbz6jIWEHLAD4JBh5LQPsGEse+LDCEFpidC+YC/HMDVztohWH0Azh95+hxpfXF2GGs94rt5WNqD3gH+lg2mxO8q1es4Ke0P9toQB2BZGb9CpHSkOhuuga6zPUizhD/0dyDgXaE88SAZsnonQmmomMFBlFRVvriqFLMPz7RiH0VzFAtZ46UxFevX7u8IDZ0rUkzvfAoLtj8HQUUhWRNmL+9s7mEtP4tiVLPNdXhcSrMGs96V3Xlij/SMpc7BD2a4X7E6JALXBeJmqnGuUv0n5eQ4uoySuNKtE7bfZ2B2hO9wpG0jbtxdahIvNBkXtnSlwW3hQ4 IKh9Ld4W wv/RKS2mH36qTRfFc+bygjlAgbhU6UjBlTpADtvhxE2DJN2HNiw22hml9Rk4f8DqUOHnmz0ETSYvXbgl9FeZuinj58Lh6ZmleGMeQuJWXenRxjqWChqzRZH4XStJ59Uh0neHl28uZRvx3oVlMR8Nsh4GVak4duffRMw8zdZTBwQzvABYckgioSNv8ehL3MeNAZkHBOT1YXc04++NgLIDExz8r8AtXUY7pJhFkEBvUgBucv6p0mbjJDG4ljADIruXiP20agwMxFAr78wJvwrCkvpEspUp4otArto1Nb1j8bL/m+Xx3FmhtgR5Y3CpVuvID3Nkcw2BZyVVOc+ySCle3hPxbzn89mcLadS/97ihPG3VsTPjOJ+QhREBPD2uBmIe8nZ+uirnm2idgJAVK4x6OIHB+eeO5PylpUczGeAb+tZy5X8HDAzMjEMaz8goVsDbdZp5qLfZOp7VJEh9bPHcudllt/K+YdHzdb9eoxsJI8kWLtdwFPt8RYpsMhdWswzr6SKNp 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 Thu, 25 Jul 2024, Michal Hocko wrote:\n >On Thu 25-07-24 13:38:50, Barry Song wrote: >> On Thu, Jul 25, 2024 at 12:17???AM Michal Hocko wrote: >> > >> > On Wed 24-07-24 20:55:44, 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. >> > >> > Ohh, so you have done the migration. Please squash those two patches. >> > Also if we want to preserve clean __GFP_NOFAIL for internal MM use then it >> > should be moved away from include/linux/gfp_types.h. But is there any >> > real use for that? >> >> yes. currently i got two, >> >> lib/rhashtable.c >> >> static struct bucket_table *bucket_table_alloc(struct rhashtable *ht, >> size_t nbuckets, >> gfp_t gfp) >> { >> struct bucket_table *tbl = NULL; >> size_t size; >> int i; >> static struct lock_class_key __key; >> >> tbl = alloc_hooks_tag(ht->alloc_tag, >> kvmalloc_node_noprof(struct_size(tbl, buckets, >> nbuckets), >> gfp|__GFP_ZERO, NUMA_NO_NODE)); >> >> size = nbuckets; >> >> if (tbl == NULL && (gfp & ~__GFP_NOFAIL) != GFP_KERNEL) { >> tbl = nested_bucket_table_alloc(ht, nbuckets, gfp); >> nbuckets = 0; >> } >> >> ... >> >> return tbl; >> } > >Ugh. OK this is a weird allocation fallback strategy 2d22ecf6db1c >("lib/rhashtable: guarantee initial hashtable allocation"). Maybe the >code should be just simplified and GFP_NOFAIL used from the begining? >Davidlohr WDYT? For your context Barry tries to drop all the >__GFP_NOFAIL use and replace it by GFP_NOFAIL which enforces >__GFP_DIRECT_RECLAIM so that people cannot request atomic NOFAIL. Why is it so weird? Perhaps I'm missing your point, but the fallback introduced in that commit attempts to avoid abusing nofail semantics and only ask with a smaller size. In any case, would the following be better (and also silences smatch)? Disregarding the initial nofail request, rhashtable allocations are always either regular GFP_KERNEL or GFP_ATOMIC (for the nested and some insertion cases). -----8<----- diff --git a/lib/rhashtable.c b/lib/rhashtable.c index dbbed19f8fff..c9f9cce4a3c1 100644 --- a/lib/rhashtable.c +++ b/lib/rhashtable.c @@ -184,12 +184,12 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht, static struct lock_class_key __key; tbl = alloc_hooks_tag(ht->alloc_tag, - kvmalloc_node_noprof(struct_size(tbl, buckets, nbuckets), - gfp|__GFP_ZERO, NUMA_NO_NODE)); + kvmalloc_noprof(struct_size(tbl, buckets, nbuckets), + gfp|__GFP_ZERO)); size = nbuckets; - if (tbl == NULL && (gfp & ~__GFP_NOFAIL) != GFP_KERNEL) { + if (tbl == NULL && (gfp & GFP_ATOMIC)) { tbl = nested_bucket_table_alloc(ht, nbuckets, gfp); nbuckets = 0; }