From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 E6C54325722 for ; Tue, 6 Jan 2026 13:51:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767707487; cv=none; b=KO6J0DeCMr8P51WuwG3UOqGxrd7hnhMRgs+f/BkxIElZPIljO9HbZTznSDbNa7TXGtpboqAhe190WOjlraW+Z5LfpMwDsI4iqbeAXzqd7OF2+QYhMKQGgQgvw5WlmDjwEs9zcENBFMDJytoSa7ojKsFqi2yEPjnSfdlQoSVatLk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767707487; c=relaxed/simple; bh=EFJI+o7t6JEWQi8Y28NsPQUK/+E2oBVY/7DJNQ65dmg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CpdEEI9QKeq3U5h7EG4uU1oCFt1cwvwwmFca6F6i03Wz/3UEgck2Y6nyqX6LZeRIe6uX1fwTX5DoOsLtjoBZJGWQzzvu5z905WORNhC7CmlT9GdQyJdvvn2zmTf0JZeFtj90YmT5gr6fTCowX0sgPwxTgfvncS9J5/QNg/AEbxc= 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=AYKCayDo; arc=none smtp.client-ip=209.85.128.43 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="AYKCayDo" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-47774d3536dso9404475e9.0 for ; Tue, 06 Jan 2026 05:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707483; x=1768312283; 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=jCoOPztzEqaTsy0dNYQf6c1IFhf7sLhplgQewyTuM64=; b=AYKCayDo6zOfZXXR/nWtjyBEqvdPqgc+FY4ERZC7g4Cwo1FvO8IRCTQWpFPnH5rjA8 QkiJErQ8TSFgAhHkPq6JrwJs1eb6IubfKh7txkskCNE9T54xiS5Qkmd2EuLK8WsGKBPd 1fM4+IW1cwcThgYAr1Ces16pbOSiouiS7K6U+Cc4cwBVH6/i01K6siS5BOmZycXxTGvH EGI9/T8su98ZblOfE7y1IUSCMI5FbGa1e/P7hc2MX+tONG/U2mcZPo9fuqWk60EfoFkL t3BVa9adl5P/rHcjuNXFar0ipKqr5LhklNkPu/9qzXbDzI+gDQWsKyD6P6qEQ/z3zbhd OXng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707483; x=1768312283; 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=jCoOPztzEqaTsy0dNYQf6c1IFhf7sLhplgQewyTuM64=; b=baC4YwGPZMbji9GIWnRmbU16uPWhXUWgYPClqMuKSjPyKMGRSa2h1ZOgA9llslXfhI CHHu2xBs7uHqBBH4RBEqjfqUS1hiVVv0IZ8ffE779tTQrm3Qfm+VokVyfdnjF2dL8dKU NJt3L5t4LUp/wK2uqyou2ZC2JTcBjdLlQeBfFrMtRMG1yX8SaNMzzJkDI6qaC30XJQ9J tqmP1wFw0PqM/Pk/fVAthqSNOhpXxZTJrNmqMEbEwHWhU5fCewy8UJQsvV0eN6LcWgdu SAF7AyP3alimQb4tRJtozJr8+Ii7YBj8YX+4d+2TWqT1OOE8Zui2T6lOeyU4e6tF4emQ O+PQ== X-Forwarded-Encrypted: i=1; AJvYcCXIgPgZFLlONTBIPAMHbvQEyujnQ8IUtfmWcyTCDDBgl68stPbpQ/e3T5gEbfXN43R8KFIxJbk8vHfhsfI=@vger.kernel.org X-Gm-Message-State: AOJu0YzdST4NPnA4mOmuetS6TH7AKSWLUzdOWzikoaFAfXWX4zn+CHKc PHRu/S1nqINJCiNoEUWvXsfvSYlFzOINsZwt18Pm9hf+JhlGURiQ6ZoJLRxKxZ80ZL4= X-Gm-Gg: AY/fxX78qZL268+yxrtRYxbLzDJXPBtMm6kjx4p0+hV7YEfDZAcgFk91GO6wjSxnvjv yE6ZJW7ZNtgcvgfJF6LQ82viHk2OOGnZ50j82qZfdukBxUIfBLsBkxv+bPyJuHUaF0t0kAXgiLq l0hJXftrSGxHCqaemCYYdgcyJCZyQpBVfJHNnb6IWHx5x2vBgebF4jTJsN/YAu2UWCSp5eoV4HI PXMPnmkfJBgayZYVrTs1j0/B+v1KrsY7lOK96vxNyIeBCo+LRwmEXQGSe3GcIBV2lsGsRtl+HAQ s6eTQOjeO0NXEZGkXt8hgR4k5XFTsRp1tJtplMV4CS6gcszjoGdq2P5DvgeSezhxGyfhVV0f6ZM 9S8w5YknfYwPzQW3wllRJ1guGYgYH+VsGbEfCoQNVrFLA0wsHlXFAnca1GoUMZDo3gl5d3CwpoF aemKkRkRXZ4UI7yc6aiWlp+QMU X-Google-Smtp-Source: AGHT+IESNrX8z008NyBGIbTqL31wCxSi3oeO2P9JkQEbEz6YZ0vWzFn0AdhDBlAvOu3JM7FeImTgWg== X-Received: by 2002:a05:600c:4755:b0:47d:6c36:a125 with SMTP id 5b1f17b1804b1-47d7f425bbfmr36053145e9.17.1767707483000; Tue, 06 Jan 2026 05:51:23 -0800 (PST) Received: from localhost (109-81-90-116.rct.o2.cz. [109.81.90.116]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7fae6699sm17782635e9.3.2026.01.06.05.51.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jan 2026 05:51:22 -0800 (PST) Date: Tue, 6 Jan 2026 14:51:21 +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 mm-unstable v3 1/3] mm/page_alloc: ignore the exact initial compaction result Message-ID: References: <20260106-thp-thisnode-tweak-v3-0-f5d67c21a193@suse.cz> <20260106-thp-thisnode-tweak-v3-1-f5d67c21a193@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: <20260106-thp-thisnode-tweak-v3-1-f5d67c21a193@suse.cz> On Tue 06-01-26 12:52:36, 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. However that would change the semantics > of __GFP_NORETRY to attempt reclaim at least once. > > Alternatively we can remove the compaction result checks and proceed > with the single reclaim and (lower priority) compaction attempt, leaving > only the __GFP_THISNODE exception for failing immediately. > > Signed-off-by: Vlastimil Babka Acked-by: Michal Hocko Thanks! > --- > mm/page_alloc.c | 34 ++++++---------------------------- > 1 file changed, 6 insertions(+), 28 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index ac8a12076b00..b06b1cb01e0e 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4805,44 +4805,22 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > * includes some THP page fault allocations > */ > 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. > + * Compaction has failed 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 > + * Proceed with single round of reclaim/compaction, but > + * since sync compaction could be very expensive, keep > * using async compaction. > */ > compact_priority = INIT_COMPACT_PRIORITY; > > -- > 2.52.0 -- Michal Hocko SUSE Labs