From nobody Mon May 25 01:14:28 2026 Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) (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 D110D3AEF4E for ; Tue, 19 May 2026 20:09:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.189 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779221355; cv=none; b=QWzKe2dYmznV4MtTnp0xQDa6LntaFNcxlZU9Y+HFC1JgqNhFf9YMdQia6G483v94ubafFP+VperCR+fdDAm3UxIdip96/lvMcJq7IC7hVAy6xCvqndvPNYs3bmMWHGd1Me/pZyv8gvkqu+cNhPShfcOfNmm3xusDSd0ONmk+OC0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779221355; c=relaxed/simple; bh=zwuULBxrvxXpiRP6RIjgBT260VJd3wz46wxmwG+rmDY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=vAJOb3w9M7eAsZawaEULV2gmuTBsvA/eAbG982NrzkxiOe4pzOLWYfdKJs2LcYJ8DSw+arcXvshZjDdDFA9GFE8hLKG8eLVGqCWvxxEAku+jPIN4r1ETFd8/pxYIaiFl8YpDLTu82aB8pUNq2TxPDwu6BJN9B09gbW9hn3jg8e0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=DfsQvan+; arc=none smtp.client-ip=91.218.175.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="DfsQvan+" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1779221349; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=HXSYodT8UUoQTetKQdVe9/Pql0Tf/W+31/8rbH/ehJE=; b=DfsQvan+3bhilGFp5EzcRQf4zy/+Ij0pQkI/O+nwLxTDp6+aBcVaPXb5sQjVy8ZKTuHf+W vtlmZO52qZJB0GbUeyCXwyvfAGhe+ZbZzpmUv8qt2aiD9IU9tMPpukVFQ4FqPsa+QZSmZW P/6wZAXzTazY6gU5AXYcd/KJTtzeOoM= From: "JP Kobryn (Meta)" To: akpm@linux-foundation.org, vbabka@kernel.org, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: [PATCH] mm/compaction: cap compact_gap() at COMPACT_CLUSTER_MAX Date: Tue, 19 May 2026 13:08:51 -0700 Message-ID: <20260519200851.141955-1-jp.kobryn@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" compact_gap() returns 2 << order, which is used as watermark headroom in __compaction_suitable() and as a reclaim target in kswapd. The computed value scales exponentially by order. For order-9 THP allocations this evaluates to 1024 pages, but the compaction free scanner's working set is bounded by COMPACT_CLUSTER_MAX (32 pages). The scanner stops isolating free pages once it matches the migration batch. The current gap over-reserves by 32x. On fragmented production hosts, kswapd will try and reclaim up to the gap, but it only reaches that threshold 18% of the time, causing reclaim to continue a majority of the time. The over-sized gap also causes 46% of order-9 compaction suitability checks to fail unnecessarily - the zone has sufficient free pages for the scanner to operate, but not enough to clear the inflated threshold. Cap compact_gap() at COMPACT_CLUSTER_MAX to align the watermark headroom with the scanner's actual capacity. Orders 0-4 are unaffected since their gap is <=3D 32. A/B test on ~100 instagram production hosts (64GB, 60s measurement): Unpatched (43 hosts) pgscan_kswapd (mean/host): ~1.6M reclaim efficiency (steal/scan): 83.8% compaction success (success/stall): 2.1% THP success (alloc/alloc+fallback): 4.9% forced lru_add_drain (mean/host): ~107K Patched (59 hosts) pgscan_kswapd (mean/host): ~449K reclaim efficiency (steal/scan): 91.0% compaction success (success/stall): 28.3% THP success (alloc/alloc+fallback): 17.2% forced lru_add_drain (mean/host): ~64K Signed-off-by: JP Kobryn (Meta) --- include/linux/compaction.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/compaction.h b/include/linux/compaction.h index 173d9c07a8952..09aea63b8a89d 100644 --- a/include/linux/compaction.h +++ b/include/linux/compaction.h @@ -2,6 +2,8 @@ #ifndef _LINUX_COMPACTION_H #define _LINUX_COMPACTION_H =20 +#include + /* * Determines how hard direct compaction should try to succeed. * Lower value means higher priority, analogically to reclaim priority. @@ -73,11 +75,9 @@ static inline unsigned long compact_gap(unsigned int ord= er) * effectively limited by COMPACT_CLUSTER_MAX, as that's the maximum * that the migrate scanner can have isolated on migrate list, and free * scanner is only invoked when the number of isolated free pages is - * lower than that. But it's not worth to complicate the formula here - * as a bigger gap for higher orders than strictly necessary can also - * improve chances of compaction success. + * lower than that. */ - return 2UL << order; + return min(2UL << order, COMPACT_CLUSTER_MAX); } =20 static inline int current_is_kcompactd(void) --=20 2.53.0-Meta