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 A901BC83F07 for ; Thu, 29 Aug 2024 11:41:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 116656B0083; Thu, 29 Aug 2024 07:41:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C6776B0085; Thu, 29 Aug 2024 07:41:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF7056B0088; Thu, 29 Aug 2024 07:41:30 -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 D03466B0083 for ; Thu, 29 Aug 2024 07:41:30 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F1F10140D1A for ; Thu, 29 Aug 2024 11:41:29 +0000 (UTC) X-FDA: 82505092698.17.0250016 Received: from out-170.mta0.migadu.com (out-170.mta0.migadu.com [91.218.175.170]) by imf12.hostedemail.com (Postfix) with ESMTP id 1534440002 for ; Thu, 29 Aug 2024 11:41:26 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=YCyLr5db; spf=pass (imf12.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.170 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724931643; 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=SKn8Wh+3LeVdT/w94GI0tUKPrlK8ASkBcZKoP1WMJwo=; b=sYvVHPhFu4/53Ku2EfOQslApgOXtMj5g0EKBf8Rk03JgW0Rx72Hyfi2JMhr2iOVuZMsFtg VRDaBWjWzYWktSPNWcOLw7DzXvaQCONK+ROcVXZwynsZEQTlgcoHkqVr0griuaf7avCTrE sQPzjWVwzovqzS8B7dHwgQdyl27CpUE= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=YCyLr5db; spf=pass (imf12.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.170 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724931643; a=rsa-sha256; cv=none; b=V9rH5jw8nUpX9kc9I/MF0DhmiSknDnU3b8HUcZ2r/JjP0+6yQSx9evQpd+GUebe4DrW1iB dR9cgPeYwtNFh90X3MKjHlf8Cpzw4/l4kAlUUIgizzue+5uMPv5vyyLpiZfIjTMHY1G/EK vXcna9tcLQennmoEpMYz/kRMjAseq6A= Date: Thu, 29 Aug 2024 07:41:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724931684; 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; bh=SKn8Wh+3LeVdT/w94GI0tUKPrlK8ASkBcZKoP1WMJwo=; b=YCyLr5dbXqcm5dotzHuyhHb9ngGEjYnQ8wN7pUllReO/ExzMV5UKv9v3ezxkb2IQdn+bz5 xa7uJrrLC1sySB4KbTtQ2k/8uT76ELG8adcRQDxAjIdbK3B7dNDv909OrO/SDVeIo6j3OZ bWt414CI3d7n5QySCSM8QW/62qUadik= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko Cc: Matthew Wilcox , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Chinner Subject: Re: [PATCH] bcachefs: Switch to memalloc_flags_do() for vmalloc allocations Message-ID: References: <20240828140638.3204253-1-kent.overstreet@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 1534440002 X-Stat-Signature: wxhz7h1e6agx6rbazwcfxahi83r1d5wj X-HE-Tag: 1724931686-482833 X-HE-Meta: U2FsdGVkX1+o7T/Mba4mxtdYSI5jQ0nqADbvlWsL+PHFztO0lgY1RuhhDW+KlIYoU04ZZY+Ghm08iLieeLkFPi5kGVims+gwCXvyKxbk+2Yrfp7d/mDfgvLeX9hzLf1E+q9CSQPKRwzBxPXJdOrbKKsXdHzIYULDke+juXLAIAPr1BNxOzhNLJ1RmIx32q0y1TgfVaNRM9BzXiCAKrpW5crr80s9RqDIx87Ju4ILsSm7hmh+6yecQiKhWpPvdAzFAmL8DwmHrwYI9wT3IhyLuYAJ0B9CnzrvBK5gD8CpSIiGID35q/PW87PmC3EnpxUiYRO2Q2+240zemCIGX1/yVEjprZ/whssrfe8ZZq14+4a2kbRaLpLHzFhEX1D41aDUuWulGtZsMN23id/ZeCbV2rxhF5vsIeXitWCvJ7lby5lE5I4mtIXn1wZnkP5gU1fummiCqS9FzScjdVbM4FNrUsNGkobHe7dltYfQ48L9ChGRd+6AnzUh/UoJGvlQZShH3VYSQFauWCcy+RGdWN8tzrXG19W0yJq5rr5J80SnzimXvx6sa+sfrp2ybYfIRQSHbqRyVpgRxDTGJPdXQzFRP8FpchXV5UcwGj5CDaG/0DUK0XLSzK3oC+bABAWSuS5GQZOvH1EBB6QJd30aL9iFplG+B+TCqpEKL+KszjFGGtD2luA9dQI7/wyQZ+ix+gbDpr8lCNOdiQGCtYuQEv6vVsSZTez9L/CkixkaN8j1WUS9LaUbeQS6VmRXH+gJFS4oWD74a9+mdcbrezUbWKvcRN0SD9TxlbRqwmx/sxjeij8UeSkJxk07PUPoWcgr/JkqTQdeqpp834mJ3KCaYbM8u6XU1NXRPmdkdI9NuW+7ObHLc3EgZTaYBLrncBAe2jEbt6CSzuKvkW8HnowxlvW2Nj2er37sDWeVl1AhYtsY5k/NlE13KHkZjYpKEDxryyHkGzjvsH8u11CHdaWFUiP 7KavuEVX YNeJffTP2awntga4ife18h7P+1pQGPLo+PFvY9xMvC8yVWRB0hISVeOaJFLhesCbWeZT3YPpqw6W718jJekMNTyN4HANUj4rPIGj1YC4A3vGDY8x8pBQeFS8E6S2BBrrxGFKfYy9h0O7cXL4PYkboFEBbggeKUw+vJuMVXGDl4LX3Qqsl0/45kGqHAUvuGaDTS+dq 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, Aug 29, 2024 at 09:19:13AM GMT, Michal Hocko wrote: > GFP_NOWAIT is explicitly documented as unsupported > (__vmalloc_node_range_noprof). vmalloc internals are using > vmap_purge_lock and blocking notifiers (vmap_notify_list) in rare cases > so PF_MEMALLOC_NORECLAIM is not really sufficient to provide NOWAIT > semantic (this is really not just about page tables allocations). There > might be other places that require blocking - I do not claim to be an > expert on the vmalloc allocator. Sure, but those are easily fixed, if necessary. We'd also want to be explicit on whether NORECLAIM needs to be NOWAIT or just NORECLAIM - those are slightly different things. As long as it's NORECLAIM that should be fine - it's really only an issue if we need to map GFP_NOWAIT to PF_MEMALLOC_*. > It seems that this discussion is not going to be really productive so I > will leave you here. I think you'll find these discussions become much more productive when you're able to stick to the technical, and when you yourself are able to listen to counterarguments. I remind you that we hash things out here on the list; we don't resort to things like "this has been decided" or "the mm community says"; you need to be properly justifying what you want to do here. And if people aren't listening to your arguments, that should be a hint to you that maybe you aren't making good ones.