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 6ECD6C433F5 for ; Fri, 26 Nov 2021 15:10:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D01836B007B; Fri, 26 Nov 2021 10:10:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CB00C6B007D; Fri, 26 Nov 2021 10:10:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B51776B007E; Fri, 26 Nov 2021 10:10:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id A7DBC6B007B for ; Fri, 26 Nov 2021 10:10:11 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5DD1E8A3E3 for ; Fri, 26 Nov 2021 15:10:01 +0000 (UTC) X-FDA: 78851416602.30.CC225EC Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf25.hostedemail.com (Postfix) with ESMTP id 9BBE6B000F57 for ; Fri, 26 Nov 2021 15:09:38 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id DAB612191A; Fri, 26 Nov 2021 15:09:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1637939380; h=from:from:reply-to: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; bh=cU0u1ErYfWJN1z5VHiy7kYCcJFmwRVG6KI1gkeUqUx0=; b=TUSWZNPKKrdfBXzvAGx2Kbhs53F5LWklUyEuRqQPxUekEie7Q6w4yPDHollgtu6eP+gCgL K5uEwT0vjdWFdbkK8Qft+2gUwGOg+9TNqkxKnIZSW7UX7Rbp8if6YunYiXYPNuviwBk2GC gDEv06tj/loWg8Mjz9BJZmUeDHJvkmo= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id BDE94A3B81; Fri, 26 Nov 2021 15:09:40 +0000 (UTC) Date: Fri, 26 Nov 2021 16:09:40 +0100 From: Michal Hocko To: Vlastimil Babka Cc: NeilBrown , Andrew Morton , Uladzislau Rezki , Dave Chinner , Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, LKML , Ilya Dryomov , Jeff Layton Subject: Re: [PATCH v2 2/4] mm/vmalloc: add support for __GFP_NOFAIL Message-ID: References: <20211122153233.9924-1-mhocko@kernel.org> <20211122153233.9924-3-mhocko@kernel.org> <20211123170238.f0f780ddb800f1316397f97c@linux-foundation.org> <163772381628.1891.9102201563412921921@noble.neil.brown.name> <20211123194833.4711add38351d561f8a1ae3e@linux-foundation.org> <163773141164.1891.1440920123016055540@noble.neil.brown.name> <919f547e-beb7-34b7-7835-9e1625600323@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <919f547e-beb7-34b7-7835-9e1625600323@suse.cz> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9BBE6B000F57 X-Stat-Signature: kdwypy7ebfum43ss8ybstp8qec9cth1y Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=TUSWZNPK; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-HE-Tag: 1637939378-340097 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: On Fri 26-11-21 15:50:15, Vlastimil Babka wrote: > On 11/24/21 06:23, NeilBrown wrote: > >> > >> I forget why radix_tree_preload used a cpu-local store rather than a > >> per-task one. > >> > >> Plus "what order pages would you like" and "on which node" and "in > >> which zone", etc... > > > > "what order" - only order-0 I hope. I'd hazard a guess that 90% of > > current NOFAIL allocations only need one page (providing slub is used - > > slab seems to insist on high-order pages sometimes). > > Yeah AFAIK SLUB can prefer higher orders than SLAB, but also allows fallback > to smallest order that's enough (thus 0 unless the objects are larger than a > page). > > > "which node" - whichever. Unless __GFP_HARDWALL is set, alloc_page() > > will fall-back to "whichever" anyway, and NOFAIL with HARDWALL is > > probably a poor choice. > > "which zone" - NORMAL. I cannot find any NOFAIL allocations that want > > DMA. fs/ntfs asks for __GFP_HIGHMEM with NOFAIL, but that that doesn't > > *requre* highmem. > > > > Of course, before designing this interface too precisely we should check > > if anyone can use it. From a quick through the some of the 100-ish > > users of __GFP_NOFAIL I'd guess that mempools would help - the > > preallocation should happen at init-time, not request-time. Maybe if we > > made mempools even more light weight .... though that risks allocating a > > lot of memory that will never get used. > > > > This brings me back to the idea that > > alloc_page(wait and reclaim allowed) > > should only fail on OOM_KILL. That way kernel threads are safe, and > > user-threads are free to return ENOMEM knowing it won't get to > > Hm I thought that's already pretty much the case of the "too small to fail" > of today. IIRC there's exactly that gotcha that OOM KILL can result in such > allocation failure. But I believe that approach is rather fragile. If you > encounter such an allocation not checking the resulting page != NULL, you > can only guess which one is true: > > - the author simply forgot to check at all > - the author relied on "too small to fail" without realizing the gotcha > - at the time of writing the code was verified that it can be only run in > kernel thread context, not user and > - it is still true > - it stopped being true at some later point > - might be hard to even decide which is the case > > IIRC at some point we tried to abolish the "too small to fail" rule because > of this, but Linus denied that. But the opposite - make it hard guarantee in > all cases - also didn't happen, so... Yeah. IMHO we should treat each missing check for allocation failure (except for GFP_NOFAIL) as a bug regardless the practical implementation that say that small allocations do not fail. Because they can fail and we should never subscribe to official support implicit non-fail semantic. -- Michal Hocko SUSE Labs