From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta1.migadu.com (out-171.mta1.migadu.com [95.215.58.171]) (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 9E4B2408608 for ; Tue, 9 Jun 2026 13:06:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781010400; cv=none; b=LWM1H+rnG32zHOs9J8uOrKPevxOZHFZOK4avEX2voVkxE4zJ7hQEhYeS7C8OQi7Mp/RDsri9S26k2zgTldNA7E+m8yORb6INAv4DtCfx9X14cpUmaR6NW335GDfHzbiyL12AIEmtG8+JiGF5A7U/fly2cPBwlZQjnQss/b0YWKg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781010400; c=relaxed/simple; bh=NH90VouvOb9kOq4pkw/KFlB7kRKPVoq/2LrEOzFdrkI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=LmFJXx21jSJVwAlQH/VBM0yKlhPCf4bUFyCAFD7vm9QQWC9m/3ZeDeVUjQ+KyPape7XLL8J/E8OpR5FebEip+x3TzLd9cw1bkar7ojKnVrc4kSChpFWCk7CajsworiqKxbnqyFjYtXdr+DARpO/ooL3Hx3ZxFMmbfQFLq6GcK+Y= 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=SvSH4jPB; arc=none smtp.client-ip=95.215.58.171 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="SvSH4jPB" 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=1781010396; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o4G/6dMhsGhQ3xyO1huMA/GT5WeZwLaeB/f24JGzosc=; b=SvSH4jPBiZx6/u4w919Lh0Jyx4oZWxts5ve2CAID2ba5LW0tFiephKSfNbvlxjweGeHQAf sUsCReJH8CKpTisYRwn/XYlbH/9Xk9t8oRAigvun9R4XcrvGG8JBopJ2CrHsAvLuv6ZZ/K wQLXqnYumkQau3eEaV6aVnpkB5jwAX0= From: Lance Yang To: xu.xin16@zte.com.cn Cc: npache@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, usamaarif642@gmail.com, yuzhao@google.com, aarcange@redhat.com, akpm@linux-foundation.org, david@kernel.org, chengming.zhou@linux.dev, ljs@kernel.org, ziy@nvidia.com, baolin.wang@linux.alibaba.com, liam@infradead.org, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com Subject: Re: [PATCH mm-unstable v1 2/3] mm/migrate.c: Prevent folio splitting from interacting with KSM Date: Tue, 9 Jun 2026 21:06:11 +0800 Message-Id: <20260609130611.88058-1-lance.yang@linux.dev> In-Reply-To: <20260609201202615oT6yd_LtIoKkGLksFaCha@zte.com.cn> References: <20260609201202615oT6yd_LtIoKkGLksFaCha@zte.com.cn> 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=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On Tue, Jun 09, 2026 at 08:12:02PM +0800, xu.xin16@zte.com.cn 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. >> > >Why do you see it as regressions? > >AFAIU, KSM and THP do often conflict with each other. THP tries hard to collapse >a huge page (which may contain many zero pages). If KSM is enabled and part of >that huge page is mergeable, it can easily be split by KSM, rendering THP's >efforts futile. > >Therefore, in our actual production environment, we typically avoid making the >same region both KSM mergeable and THP always. Right, some setups may choose to avoid using KSM and THP always on the same region. But that is not something the kernel can assume :) David noted in the RFC that QEMU may use both MADV_HUGEPAGE and MADV_MERGEABLE, while KSM can be enabled later system-wide. And I think Nico means something different from KSM spliting THPs in general. KSM has been able to split THP before. the new part from b1f202060afe is that a KSM-triggered split can also remap zero-filled subpages to the shared zeropage, outside KSM's own use_zero_pages/pages_to_scan controls. Maybe the changelog could spell that out :) > >>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. >