From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E7BAE3563F4 for ; Wed, 11 Mar 2026 08:42:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773218555; cv=none; b=tDsbsqGKSLnDRGheQWIgSuwdo1zIBdShsoBu2JM1pgopsciVkdo0E9yCuYX0gARjNVeuMBijBU6o6DUnVSoA/WjCA7byvQM2D+B0p5j8n6PldRRILwWtW5aUgnyvDe2Lhk75PBettL4GNLk3cG8P/aL8JARyqYXtmQgxS111xb4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773218555; c=relaxed/simple; bh=cSOw5vUBbeauTKMm/XukR2FfKyjy+86zqmz8T4NdTAU=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gMLo0sVtUjDdKo4GihAvdHoioHHj++XzNXikyB0gLZ5/ahZ1N3Y8KAUSN5C7UmUxKylpoL8CgStIZeuqADVTLsq2oenaJ3T00FVO9zGQonJGNwSF/BEuwVEb05Q+L6RRSucH2pRF1DBE10PgODNXOQjVTRbUZwA5uLuPndzZ31M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=aqPs7Z2m; arc=none smtp.client-ip=209.85.167.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="aqPs7Z2m" Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-5a13f6bcbf4so6443092e87.1 for ; Wed, 11 Mar 2026 01:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773218552; x=1773823352; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=do4vHEgx//2ZE2oBeVySUVvd3IyqCD6MeIi5bwH33io=; b=aqPs7Z2mQMKxAhfNcrAVtgUe/c0tlYG4iBfs/KM/dAEbIL8IPxioKtah7UlNsZwx8s bampRsfePkwhXIbB/hcmHsd7oABWWnUmTTr6RVTp1OVXhvO55QQapsH1nczuIvgPvFKm ZJ8YTurZ3aqC/cHUGdOLD8lR5D0I7gSQ+3GWQ1w8l+RpLd3RbJc8Iqgh/78WAse3lJUZ CBdHGJa/ZWpVtWQEkb+AB8GCbCwXgn4cX5lfAgVtO63EYrXdagqbzKriW22NPO5vhrpn LGTOY5173E9InAkHY7bS9dvrXrRrumj2Y2QgVse3JMbSW7vGlD9mUJi+DnEGIIjd4UdV fzmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773218552; x=1773823352; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=do4vHEgx//2ZE2oBeVySUVvd3IyqCD6MeIi5bwH33io=; b=TLDc9IoQEbKY6g3o3ildGm7lxP/+ARMBKmr5Lfpq+uNNIwPJ7GQB7sN3Kx6TVDuiMi lF/ynCF8Cl3ALq27ijdGUl0vxd9LuTpfRLrEcZokV+nUWDuih86f/D0GbP02vEnxJP0o DRyRaFEWNPpW6F7BrGYCIgoIBbzKaig+AKw/JnMi6HKEwCz//8+Mfxi643tl7qrrA3dv jzUKCLayRhPrwoYgnYQuvjl2n232DueC0zdIhxGDM5BFNCCp85hJuI4vik51yEchDuiH KPjUzV+7DZDWyJHGIoVZNEToGuMCgLpSBMW77yd84HEsgE0UY9n/9WA0MBSjqVnN/bq2 iEDw== X-Forwarded-Encrypted: i=1; AJvYcCX1PEUW/QsQGxAduD6Oeg2CYiYR5iwbYX0SmYT6y4gg6KMbvwBP2mCGvo3Q3T2g2FYxq0FbB4N7yGnyiTg=@vger.kernel.org X-Gm-Message-State: AOJu0YyLa8HIDUzghlluscfJlBhh8nacecBSTJkQF50mFjKBxJcE6qxv gZNE81a8cNpLZLi49n1R+Ve/vyYDKQzLA39+vi2CibDOoTxNkkqDfStB X-Gm-Gg: ATEYQzwpULBnpouQBDJHbb3FawIgCbZ2SBpXSGqXS2GD+yEUMu+q4f3CutfBvm0oKtC XbaBBQGqRy167zsB05ANeURU9djB5xdzLGyW1oCXtVvGK7JPRsk3lws0tdP0aTuNZCVY7kc45q5 vL6h4sIgfgeq5NEBa7aPsK1c5lrv+jLHKbtr7JglGqo/59ynf4sMAND/moaB+hTNnEzqzdrSSjm N8U85IUZHxjh3wJkmhZ1Nuu7HijzweGVHTA1+e8BUahSmWOLA1o/3r8yh5ME4nVScqK8xtcnjo5 2BWSyR7trJRulq8RRJWREj9WhcOHcoTjpXtFrlXLsqPLdTV29LdaDkG81zfDiY+V8VPCRzl8QlT U3Px4Rm2/xW15FraXiYPBQV2Q1ryT1MP+xeuDQp3MbFjDDDJQJ2KlPmih/vc6xXoRrtWpTYGn0l 6LOfBR7Ma4v+8JKyXfcxBYSyh4PBDLUXuIy8eZ8VynQe68HSekXg== X-Received: by 2002:ac2:5627:0:b0:5a1:1e11:7532 with SMTP id 2adb3069b0e04-5a156cbd1d1mr442823e87.24.1773218551777; Wed, 11 Mar 2026 01:42:31 -0700 (PDT) Received: from pc636 (host-95-203-16-219.mobileonline.telia.com. [95.203.16.219]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a15636206bsm289527e87.67.2026.03.11.01.42.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Mar 2026 01:42:31 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 11 Mar 2026 09:42:29 +0100 To: Andrew Morton Cc: Michal Hocko , 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: References: <20260302114740.2668450-1-urezki@gmail.com> <20260302114740.2668450-2-urezki@gmail.com> <20260310155914.9c03a9f4cc2f433fc741e222@linux-foundation.org> 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-Disposition: inline In-Reply-To: <20260310155914.9c03a9f4cc2f433fc741e222@linux-foundation.org> On Tue, Mar 10, 2026 at 03:59:14PM -0700, Andrew Morton wrote: > 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? > IMO, we should drop the patch as it is not complete and replace it by the [PATCH] vmalloc: support __GFP_RETRY_MAYFAIL and __GFP_NORETRY https://lore.kernel.org/lkml/20260302114740.2668450-2-urezki@gmail.com/ -- Uladzislau Rezki