From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67F9327F01E for ; Tue, 10 Mar 2026 22:59:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773183556; cv=none; b=jRYd6CIF9AJEplsG9yBkpdTLnnAUQa34FwZ5DpLR0LHhY2Iidt5EM7SG1rEUez6+yZ+83onKskiWQeIfXNOKiVXCP9FSiSXZTD2C95NI4ia5SBM6DCauO/A+2B9WkLspWF9QHLWSfeY9p+G3HDOgn4/puS1Cu+wpZ2rpE1Jv0+I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773183556; c=relaxed/simple; bh=BjqkdCeMdNOKbxIQrGEVaJbY6EsiwMruzUZiA45PG3o=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=PspXJxtYsuBWEMb7FqnhXPLYiBPkWQtpw8lV1SAFs2Fcuz1RahNWNPrAUFzQHka4az26lcR0eeKfnuq0XTUAqbnm1VkTOww1ymewaFEEmEQbT0WYDDU91cwsoGjLflcBTrFVHqiXGotf6j5MIOl7hYALTR2R8QFCRx4qsYEriso= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=KxsWv8r2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="KxsWv8r2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A49DDC19423; Tue, 10 Mar 2026 22:59:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1773183555; bh=BjqkdCeMdNOKbxIQrGEVaJbY6EsiwMruzUZiA45PG3o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KxsWv8r20VHoztPpkKSLzm6o1hyzAjDLMCFIAjVIRZ+mrKX+t98XMM0JGrfJFILmV itBDuqYDyTdXlI+YE3Z9KphQ8sOPA5hUOFG+dgq/SxKylpZKcvR8Jxhet9ZoHu1A+H PEZAzZhIoa5NJI0b70dgfpakeebcNCeLrhQI6bMk= Date: Tue, 10 Mar 2026 15:59:14 -0700 From: Andrew Morton To: Michal Hocko Cc: Mikulas Patocka , "Uladzislau Rezki (Sony)" , linux-mm@kvack.org, Vishal Moola , Baoquan He , LKML Subject: Re: [PATCH] vmalloc: support __GFP_RETRY_MAYFAIL and __GFP_NORETRY Message-Id: <20260310155914.9c03a9f4cc2f433fc741e222@linux-foundation.org> In-Reply-To: References: <20260302114740.2668450-1-urezki@gmail.com> <20260302114740.2668450-2-urezki@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 2 Mar 2026 19:51:25 +0100 Michal Hocko wrote: > > I wouldn't do this because: > > > > 1. it makes the __GFP_RETRY_MAYFAIL allocations unreliable. > > __GFP_RETRY_MAYFAIL doesn't provide any reliability. It just promisses > to not OOM while trying hard. I believe this implementation doesn't > break that promise. > > > 2. The comment at memalloc_noreclaim_save says that it may deplete memory > > reserves: "This should only be used when the caller guarantees the > > allocation will allow more memory to be freed very shortly, i.e. it needs > > to allocate some memory in the process of freeing memory, and cannot > > reclaim due to potential recursion." > > yes, this allocation clearly doesn't guaratee to free more memory. That > comment is rather dated. Anyway, the crux is to make sure that the > allocation is not unbound. The idea behind this decision is that the > page tables are only a tiny fraction of the resulting memory allocated. > Moreover this virtually allocated space is recycled so over time there > should be less and less of page tables allocated as well. > > > I think that the cleanest solution to this problem would be to get rid of > > PF_MEMALLOC_NOFS and PF_MEMALLOC_NOIO and instead introduce two per-thread > > variables "gfp_t set_flags" and "gfp_t clear_flags" and set and clear gfp > > flags according to them in the allocator: "gfp = (gfp | > > current->set_flags) & ~current->clear_flags"; > > We've been through discussions like this one way too many times and the > conclusion is that, no this will not work. The gfp space we have and > need to support without rewriting a large part of the kernel is simply > incompatible with a more sane interface. Yeah, I hate that as well but > here we are. We need to be creative to keep sensible and not introduce > even more weirdness to the interface. Was that an ack? I'm still sitting on Mikulas's "mm: allow __GFP_RETRY_MAYFAIL in vmalloc", which has Reported-by: Zdenek Kabelac Acked-by: SeongJae Park Reviewed-by: Anshuman Khandual I'm unsure how to proceed here?