From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 BCE032773E5 for ; Tue, 16 Dec 2025 16:28:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765902522; cv=none; b=qD381d7FknG4a73QJa/YekJj1ER7qzQADDFphdT7UapFlhuyx8SlazU8CpM1ueskzD9nJo73hEkZ1eQGy/8xDDfpIh/uFl1qHLxSW3Zg3ZyWL5yqiAQUgo9qnm2hbyrw8LR0gLWAmSUELHEmml1BUPY7T88b2/zvnmzgkVxXaes= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765902522; c=relaxed/simple; bh=VqLw6/J3Jdrb0KRHT7Uycy/ZkLD+2dnn+gjEf/WcNxk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aeGXoO9PHC99x3rQjjoYMqEpHX+QTyPUPP/RXkNb1/TnTZ+HFyKPKTNWDVVnJL/JzZJu5bGd7JhfSdC+0uUsCPQ81Y7zumbRoMgj0lZ+ic8ldbG20hYJyGoY2IJX5QLjBXZSCPk2Bmv7Bzfc+X0EY/Z7+9h9k+yUA83fIYCFUiw= 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=KsgFKWb8; arc=none smtp.client-ip=209.85.128.48 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="KsgFKWb8" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-47bdbc90dcaso595215e9.1 for ; Tue, 16 Dec 2025 08:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1765902516; x=1766507316; 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=RxeKMLaOT+Gmz4/OdhDrThGJPpi1R6U2vxRByvnAG6Y=; b=KsgFKWb82hwcybRdeshvn/3K0gs48EKWDD1yJWMPi2tUAQVd2nHGZSBavm8nl7IysY k1bBUxyxEmZcRNitVn5zqhhOCyAmVqu1tJsrzanH6uOJ9/HhtRgoaRWjaf/MDFJYiRvX 07QSlW5KAG6A/Ov5bc9Gz6hCRZJH7ofb0TpzF+AjqAduFwqMZa8RIBiDWPRUrr/sYNwz dmTvBQEMBZaiJrtufe2tz5Go9QFzTD2LseDHFFsWQIPU+IgSJuPGDbMNCcQh6u2tv61d xuzQWk6P+of35mZ7hfAENbfbpMO6KNEOQlVHrqdltZClKNijKmKkZdRUKnxBa92fQRTF 92MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765902516; x=1766507316; 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=RxeKMLaOT+Gmz4/OdhDrThGJPpi1R6U2vxRByvnAG6Y=; b=lOy1U1jseKC9XNeBVMAX6Pa6jxvY1hf6SWmav6pzJ7J8y1R1GUxf21F2afwHcuRKWo GiA9CPG+3OdyJFWqPH6m//++w9EqxVvDX37ooKG8usveeO5cFF9UfR/XJDh3+u6oPq87 r9tgB7y50nYrCeS1tXT62bc7yC6Drex7RFRJuko1hcWWqqrOBqAvB4qHFyCdWzcIbD3S CbnqBKaYVmZT6wmN2+Dj/rz0srFH8gndpOFus8e/cPz31Mr3ECnfkaRCxmdbHnk5g2a2 TqwK+a/OF5iSq3qkuVVQZQf2d91a095lJonq4lI77kqO8eXjNaLowoXFPeHyAyCaOO9s H/zQ== X-Forwarded-Encrypted: i=1; AJvYcCWdo4wWDAu2OktWuhROnOyyVsHjO9biql3uAVeOg34uDSZG0gqXAIar2qwX63WHEKQF0IFF8Amt0EBad+s=@vger.kernel.org X-Gm-Message-State: AOJu0Yxu2UTk2YACNFOMG41MW+FBZ+4dDI2qXUjJ00YQy/gdIsKJQfoC RfO/P3Ih7MEM/t6MMm+CXNMXxZs11uie2v1JJK0u8knEfWn9ElgTXUulkJbF8vN2XQo= X-Gm-Gg: AY/fxX7K0z+hoAPSztWa/gYP+19kCMeyE+JHmFZr93kc7MVGR3yIqrcJhgaGDbHXwQ6 1SwHPpeEMgFtwjQWElX3Cl5pMM9hgVWKi+8aSjzNmqsMHP1qzLEGLtyWLdN4BtEDaS7Z7NveMQP /iMZH1SeSITFSPvdHfVTArvYbxXzMaxHltSJPW9zKHeBvSWeNIfZnL7ExLeSR3miLzaKMk0uf38 Kg9tI4CY2GtrlLXXHrdYBr5FlPVB3B7hYrUNav0oWoXX9eZC3Rgyingl1pXZ+Fo6qM5YA79gzXf iMDiMQ+X3c2R+ey9p+t6I9eA4PW3dOWGuTpNDkScYNEuCIk2B33SE8Yraadz0su8CQiuVESUByT 25im1TUO2/M2Sdspgr3xWlwJm9p2pah9T8NOFoAZhmRFlKdumpZWt1gJRZo7YU8jEr6GGZf/Snw p7HupA81RI48xSm5Wl2yNKlee2 X-Google-Smtp-Source: AGHT+IHF/ZrwzkXQkFGXwSJeeyzB3kQ8MoRC2nTu2wXkDipm8cdXjLOlcxh6nRuI4cVhlyEpCnkYsw== X-Received: by 2002:a05:600c:524b:b0:477:bb0:751b with SMTP id 5b1f17b1804b1-47a8f90d716mr159410765e9.27.1765902515830; Tue, 16 Dec 2025 08:28:35 -0800 (PST) Received: from localhost (109-81-92-149.rct.o2.cz. [109.81.92.149]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-430f38d01d6sm21590098f8f.8.2025.12.16.08.28.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Dec 2025 08:28:35 -0800 (PST) Date: Tue, 16 Dec 2025 17:28:34 +0100 From: Michal Hocko To: Vlastimil Babka Cc: Andrew Morton , Suren Baghdasaryan , Brendan Jackman , Johannes Weiner , Zi Yan , David Rientjes , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Joshua Hahn , Pedro Falcato , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC 2/2] mm, page_alloc: fail costly __GFP_NORETRY allocations faster Message-ID: References: <20251216-thp-thisnode-tweak-v1-0-0e499d13d2eb@suse.cz> <20251216-thp-thisnode-tweak-v1-2-0e499d13d2eb@suse.cz> 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: <20251216-thp-thisnode-tweak-v1-2-0e499d13d2eb@suse.cz> On Tue 16-12-25 16:54:22, Vlastimil Babka wrote: > For allocations that are of costly order and __GFP_NORETRY (and can > perform compaction) we attempt direct compaction first. If that fails, > we continue with a single round of direct reclaim+compaction (as for > other __GFP_NORETRY allocations, except the compaction is of lower > priority), with two exceptions that fail immediately: > > - __GFP_THISNODE is specified, to prevent zone_reclaim_mode-like > behavior for e.g. THP page faults > > - compaction failed because it was deferred (i.e. has been failing > recently so further attempts are not done for a while) or skipped, > which means there are insufficient free base pages to defragment to > begin with > > Upon closer inspection, the second condition has a somewhat flawed > reasoning. If there are not enough base pages and reclaim could create > them, we instead fail. When there are enough base pages and compaction > has already ran and failed, we proceed and hope that reclaim and the > subsequent compaction attempt will succeed. But it's unclear why they > should and whether it will be as inexpensive as intended. > > It might make therefore more sense to just fail unconditionally after > the initial compaction attempt, so do that instead. Costly allocations > that do want the reclaim/compaction to happen at least once can omit > __GFP_NORETRY, or even specify __GFP_RETRY_MAYFAIL for more than one > attempt. > > There is a slight potential unfairness in that costly __GFP_NORETRY > allocations that can't perform direct compaction (i.e. lack __GFP_IO) > will still be allowed to direct reclaim, while those that can direct > compact will now never attempt direct reclaim. However, in cases of > memory pressure causing compaction to be skipped due to insufficient > base pages, direct reclaim was already not done before, so there should > be no functional regressions from this change. > > Signed-off-by: Vlastimil Babka I like this because, quite honestly, us trying to over-optimize for THP (which seems to be the only costly allocation with GFP_NORETRY) has turned out quite tricky and hard to reason about. So simplifying this wrt. to the compaction feedback makes a lot of sense. Let's see where we get from here. Acked-by: Michal Hocko Thanks! > --- > include/linux/gfp_types.h | 2 ++ > mm/page_alloc.c | 47 +++-------------------------------------------- > 2 files changed, 5 insertions(+), 44 deletions(-) > > diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h > index 3de43b12209e..051311fdbdb1 100644 > --- a/include/linux/gfp_types.h > +++ b/include/linux/gfp_types.h > @@ -218,6 +218,8 @@ enum { > * caller must handle the failure which is quite likely to happen under > * heavy memory pressure. The flag is suitable when failure can easily be > * handled at small cost, such as reduced throughput. > + * For costly orders, only memory compaction can be attempted with no reclaim > + * under some conditions. > * > * %__GFP_RETRY_MAYFAIL: The VM implementation will retry memory reclaim > * procedures that have previously failed if there is some indication > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index e6fd1213328b..2671cbbd6375 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4763,52 +4763,11 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > goto got_pg; > > /* > - * Checks for costly allocations with __GFP_NORETRY, which > - * includes some THP page fault allocations > + * Compaction didn't succeed and we were told not to try hard, > + * so fail now. > */ > if (costly_order && (gfp_mask & __GFP_NORETRY)) { > - /* > - * If allocating entire pageblock(s) and compaction > - * failed because all zones are below low watermarks > - * or is prohibited because it recently failed at this > - * order, fail immediately unless the allocator has > - * requested compaction and reclaim retry. > - * > - * Reclaim is > - * - potentially very expensive because zones are far > - * below their low watermarks or this is part of very > - * bursty high order allocations, > - * - not guaranteed to help because isolate_freepages() > - * may not iterate over freed pages as part of its > - * linear scan, and > - * - unlikely to make entire pageblocks free on its > - * own. > - */ > - if (compact_result == COMPACT_SKIPPED || > - compact_result == COMPACT_DEFERRED) > - goto nopage; > - > - /* > - * THP page faults may attempt local node only first, > - * but are then allowed to only compact, not reclaim, > - * see alloc_pages_mpol() > - * > - * compaction can fail for other reasons than those > - * checked above and we don't want such THP allocations > - * to put reclaim pressure on a single node in a > - * situation where other nodes might have plenty of > - * available memory > - */ > - if (gfp_mask & __GFP_THISNODE) > - goto nopage; > - > - /* > - * Looks like reclaim/compaction is worth trying, but > - * sync compaction could be very expensive, so keep > - * using async compaction. > - */ > - compact_priority = INIT_COMPACT_PRIORITY; > - } > + goto nopage; > } > > retry: > > -- > 2.52.0 -- Michal Hocko SUSE Labs