From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 55F36184524 for ; Wed, 11 Mar 2026 12:45:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773233143; cv=none; b=rmDt/nArg2KLAe/t9EgMWMkCAF2Z6dw8r4+sm+7GNja1Tpm+XajZp+ZSSaxBBq3VRssyrKokx6pEB75svFK3aap0FwrpDo2c4vRN32ClhX2eCJqNYbNJ/JuF6L4kadELV8gdIme1oIV3JrZOXp1fC/29uA2+SAlRAQ8IsKyThrg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773233143; c=relaxed/simple; bh=5JtbpjJ2GAu+Hyadud8qVIdNrkT0JenWZ9nggnil8bc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RKmPsrSR0UoL+kQHh1SPzm7Xkpt9YpnvnEQb0tBuA5KM1Fi02wxX4vgkNu8VlUtwx5/5NT8ObKepGEeI7c3GOTKZH27DvIMpvul2sVQwN8hGRQSZRtiMtFLJE8Dnduma9sTloZGhi53IyCOV1hP1Ae9R3bN12GAC51rDmWyHOoo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=cD+Ar5UZ; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="cD+Ar5UZ" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-439cb5af25bso4281507f8f.1 for ; Wed, 11 Mar 2026 05:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773233140; x=1773837940; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=yP/ZBBLN23AWwEEAdVB0ZzTgoRWK0abJkbcKiseHvC4=; b=cD+Ar5UZ/O6Z8LkGsis07U8PGtH1ERkLqAjJthHBCobdP2fNHl89+4YgYxHyR2xymS YDUojxdCLhRmXLl0UO1Q/o0sIWPuGfJ5+0U9bjhoW1o4f4WYlSEwQH/1sZhG0T9s25Eb 6IFTMxCnVd12BEKtnGAJTBQKhdj02S+c+jYNBzn9CUpz+ei3jcSpyUC7VJlGK0CxsaaY MslfMTZaye/Q8DHRekEQR+cdgZHBTpdOtjtdJP0bNEELUAeL2x0nenu+Wg3DnduqxDSH lzDlURX+WEiq9PrYR5NX4lo2OQnWA/qg2pIMVEeduHWm9dyMOqYayzScvvKAONDUChee HWvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773233140; x=1773837940; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yP/ZBBLN23AWwEEAdVB0ZzTgoRWK0abJkbcKiseHvC4=; b=awq/4NcEXDoiO6ymTZaMPLQCGImoaUrLeQTneivMvZa6/6NKFVn7ZSD0fY0Dk5CfjL 6ftmxHVGl+1JjAY08IP2gARZjCJs2DzkF9QALvs4WQB7ajESm8WL0ZG6R01rONiLT4XA xc4PNAXKegStV0QhdHBQ47OD5xCyukDCuIcKMDAb9cFx7PgMQh7xAiP1EbpGX0Z05/Kr YmkvAbPq1f96oqxb1nD2mfV4jRSHqZbDd4n3kuqBykjDoOCnIfyE7Yq0GCiZHsnaV15g 17tg4TM3UouOgmWE8wBpFY5zcfT3k6kffqqgGpty7dnKUjvEsQ9l4W27x6kroSUZd2j7 PA2w== X-Forwarded-Encrypted: i=1; AJvYcCV8fgidQSoHdr41rMYuAyVOf/h9zukMSQdk0e3lP16+1LrtxNjJH94kCGywKCbon9PQpu/JGkZgx024ryE=@vger.kernel.org X-Gm-Message-State: AOJu0YyN1WykbBDhFUuBMlEMZ+bcHcOYaFLHCg/Lb1WlMpwJuvKXGd0T gFmlLXGZO2QP0IL6NHFOia6T0hQFk82t9/AbAIUmjzsSAexoOMPCrFIi7N3BBgz/AWEcxMgv9eR NIvJd X-Gm-Gg: ATEYQzy4tahd+H2wHH1A9agHX812Yv/ROkFxOkDeMgAPCKiTORgvyy8dwFdSx+lAqTv Z+nQKmJzXSFkLr/i3W21I1l1MT9aKlZKyuk3Sa+1Z14PrY+6I7he3IA6cVQypXn7XtDBxhI8UJG CeUFynmp7gl7dyP5qtCFIvOjVFLa1CEshobBXJmSPnPsfYjlhSWTksAzcFO4kmJkxz/9DB4Jods D19E9091nr9xhMycVLP75V6XxROx0X28jaQRAnZys2PEuoV5+jORNpKKpsVQkTY5FhAAe3Or1rt 56OMqR7IYJSZJ9pc+V0Qqchng/heXaZeYvrdc1ssNi2MShU4nt9Rfk5t/MTc0VVInxLiXSFF2OB WBMYG95dmN+sce/uExHUKQQwmsZ5nkIZt/DFGsnKcPKLgadE+344MHQalNM/5NXPBkIIt8NCaLJ bSinBtYjsDnyYJna10mCUTaP73tdb8HG/KOhyB X-Received: by 2002:a05:6000:2584:b0:439:cd26:ce0c with SMTP id ffacd0b85a97d-439f8200be0mr4368266f8f.17.1773233139665; Wed, 11 Mar 2026 05:45:39 -0700 (PDT) Received: from localhost (109-81-87-209.rct.o2.cz. [109.81.87.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439fc0ba972sm1404494f8f.24.2026.03.11.05.45.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Mar 2026 05:45:39 -0700 (PDT) Date: Wed, 11 Mar 2026 13:45:38 +0100 From: Michal Hocko To: Uladzislau Rezki Cc: Andrew Morton , Mikulas Patocka , 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: On Wed 11-03-26 09:42:29, Uladzislau Rezki wrote: > 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 Yes, that patch is not really correct as it allows to trigger OOM killer during pte allocation. > [PATCH] vmalloc: support __GFP_RETRY_MAYFAIL and __GFP_NORETRY > > https://lore.kernel.org/lkml/20260302114740.2668450-2-urezki@gmail.com/ ack -- Michal Hocko SUSE Labs