From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 B5A2333AD9C for ; Tue, 9 Jun 2026 14:26:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781015212; cv=none; b=toqH0hiVykdKtbMdO1gG8TYiqLKaqJQdKrP54aCfRMG2SV15c3+HtIlwl8bUQdI2UPil2tmz58/B0hxS2te1sSlk94XemdsT0efiZOWz2yPoX/7lNwcpJgpXsKrP7AizrOhSX8orsPTSug1FPu/JRjmQHP1v2vKFf+urFp9rzZI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781015212; c=relaxed/simple; bh=577g7hf9HGrNA7YIT8JEwnfs+otCa/oQtG8JrExAb44=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WOCHxnE0TEnK4gJsKtsd7J1e+o8C84Bv4HRzPVYpX9HJOv1t7T5kLOT1MC/vbILJrHZL8rkP1nPIGMbqdV3Unx+kJ8saH3edwhQRSrd3uDUlrLbUFNoqGUSYUlwkwucpnP0x6Fyaud9I4fFD6yd3mXqh+Rlod6oNE25AOHN7PIw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=D5AHoeDv; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="D5AHoeDv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 26C911F00893; Tue, 9 Jun 2026 14:26:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781015211; bh=UKRI414IfLHNNeYwOL/nAAWOqGtR7JlYa1a+TkI80SU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=D5AHoeDvOTSuS+c9WN66Zv2jy+bHsL1T2USkxRt494TKRa7W9h8il6Gknwx18UBCH 3PXZi4ikQQP75Xw1WS26zhyiVdg0j0JR3tTyRg4prn9e9qRoDGsaXesw2Lph3W4Ro6 h5y9x+Rd0tJehXvqLtKs6MzWNWsr5uTdNWRKIatNgMr/CjVLgWC/osSO9W9LxkBlTs mzeJ+gGGUO3PIHLLP9jVj5AzwmycmXeCqJY0flLZgiT4gAS3rjQoIfPW1wOQcT6Pul d4hM0kCWNtY3Vb8CvXLzeP//3npyp5k+Nw/ibfFikW+hAvPLjpSraeaUhwD6HkyHAB upA13YlcG1NDw== Date: Tue, 9 Jun 2026 15:26:43 +0100 From: Lorenzo Stoakes To: Nico Pache Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Usama Arif , Yu Zhao , aarcange@redhat.com, Andrew Morton , David Hildenbrand , Xu Xin , Chengming Zhou , Zi Yan , Baolin Wang , "Liam R. Howlett" , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple Subject: Re: [PATCH mm-unstable v1 2/3] mm/migrate.c: Prevent folio splitting from interacting with KSM Message-ID: References: <20260609114619.144416-1-npache@redhat.com> <20260609114619.144416-3-npache@redhat.com> 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: <20260609114619.144416-3-npache@redhat.com> On Tue, Jun 09, 2026 at 05:46:14AM -0600, Nico Pache wrote: > Since commit b1f202060afe ("mm: remap unused subpages to shared zeropage > when splitting isolated thp"), splitting an anonymous THP remaps all > zero-filled subpages to the shared zeropage via TTU_USE_SHARED_ZEROPAGE. > This flag is set unconditionally for every anonymous folio split, > including splits triggered by KSM. > > When KSM is enabled with THP=always, this causes two regressions: > > 1. use_zero_pages=1: KSM calls try_to_merge_one_page() which triggers > split_huge_page(). The split remaps all 512 zero-filled subpages to > the shared zeropage at once, freeing the entire 2MB THP when KSM only > intended to process a single 4KB page. This bypasses KSM's > pages_to_scan rate limiting, causing ~1GB to be freed almost > instantly. > > 2. use_zero_pages=0: The same split side-effect occurs through the > stable/unstable tree merge paths. Each pages_to_scan iteration > triggers an expensive split_huge_page() that silently frees 2MB, > while the scanner wastes cycles on tree searches for zero-filled > pages that were already freed as a side-effect. > > Fix this by restricting TTU_USE_SHARED_ZEROPAGE being set in the case that > KSM is running and the VMA has VM_MERGEABLE. > > Fixes: b1f202060afe ("mm: remap unused subpages to shared zeropage when splitting isolated thp") > Signed-off-by: Nico Pache > --- > mm/migrate.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/mm/migrate.c b/mm/migrate.c > index d9b23909d716..f410f972fc5e 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -304,6 +304,15 @@ static bool try_to_map_unused_to_zeropage(struct page_vma_mapped_walk *pvmw, > if (PageCompound(page) || PageHWPoison(page)) > return false; > > + /* > + * Let KSM handle the zero-filled page deduplication according to its > + * own rate limit (pages_to_scan) and policy (use_zero_pages). Without > + * this, a KSM-triggered THP split would remap all zero-filled subpages > + * to the shared zeropage as a side effect. > + */ > + if (ksm_is_running() && (pvmw->vma->vm_flags & VM_MERGEABLE)) Please use the new VMA flag API. This would be vma_test(pvmw->vma, VMA_MERGEABLE_BIT). > + return false; > + > VM_BUG_ON_PAGE(!PageAnon(page), page); > VM_BUG_ON_PAGE(!PageLocked(page), page); > VM_BUG_ON_PAGE(pte_present(old_pte), page); > -- > 2.54.0 > Thanks, Lorenzo