From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 C759B34A791 for ; Fri, 15 May 2026 12:28:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778848113; cv=none; b=T/AvtUd1kKTojxORq0MJMkbs8QX0mKxz92x7d8v7Ze89RYNXWqdQ//U/qqP3GoFsSgZrB21Th2YRi251k9OVg+ospEmkiiizJ8NeUldnO1VhVjhoUHUtWYnGTjIgCqLwQDOk1yyT/vUdfgfDsbzkP7XifiWaa/5oRL6EU/LLavs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778848113; c=relaxed/simple; bh=Mjdo9a6AaQT7Z/mPNzEEoDf1qpwjrEf9KTXGEdd3EG0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=T6fvMxha57sv+p1Vnuh77Q/y1SzBOC2PeojPPYRrDRV9q1yGQb3K0AQto1+K26omibT40cENCNs7fT4ZajZoz5g+sVcdjssvjkcUuzcU5Fcvocdt4RrayxPG0JU8fSz7tF5lqG7Of9m3+so5tzOkYq7raUDA5Rb54tZQbUiWZ7Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IXQUuydG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IXQUuydG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77805C2BCB0; Fri, 15 May 2026 12:28:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778848113; bh=Mjdo9a6AaQT7Z/mPNzEEoDf1qpwjrEf9KTXGEdd3EG0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IXQUuydGwkyU+ZDAKyAQMuwioO3FnEQEqD748my00KnFyvMMfb58eSb7NvcRBCl+d lXgNeFRzwCaGI39BAZPK7relfEu7Q2nkpF5HrLsPW/zCi2P9ODKx290mlfnXysboyZ E6xBT5cal2ABc8/KvWn84+FV+NiX1Qu7+8Wte04WTaPwtNA50pHoFbCVvYGizPjQ2N CK4gpmG50XcbfbVnSy3jay79U/1MNDEX2H/7Lw2HOe/0vkU5+yt4c/8azLwdJeVYHD dskk7uzzzIW37B1KtnbbG0jResIq11nDHhF4kU0tJunpYJL9M2Qem/miTkysilHDYM h7KBtiesdPOdw== Date: Fri, 15 May 2026 13:28:28 +0100 From: Lorenzo Stoakes To: xu.xin16@zte.com.cn Cc: david@kernel.org, akpm@linux-foundation.org, hughd@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, michel@lespinasse.org Subject: Re: [PATCH v4 4/5] ksm: Optimize rmap_walk_ksm by passing a suitable address range Message-ID: References: <20260515151344118ESEm1fT7x-Gd6kodR8VVq@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=us-ascii Content-Disposition: inline In-Reply-To: <20260515151344118ESEm1fT7x-Gd6kodR8VVq@zte.com.cn> On Fri, May 15, 2026 at 03:13:44PM +0800, xu.xin16@zte.com.cn wrote: > > > diff --git a/mm/ksm.c b/mm/ksm.c > > > index 0299a53ba7c9..a13184d00759 100644 > > > --- a/mm/ksm.c > > > +++ b/mm/ksm.c > > > @@ -3200,6 +3200,7 @@ void rmap_walk_ksm(struct folio *folio, struct rmap_walk_control *rwc) > > > hlist_for_each_entry(rmap_item, &stable_node->hlist, hlist) { > > > /* Ignore the stable/unstable/sqnr flags */ > > > const unsigned long addr = rmap_item->address & PAGE_MASK; > > > + const unsigned long vm_pgoff = rmap_item->vm_pgoff; > > > struct anon_vma *anon_vma = rmap_item->anon_vma; > > > struct anon_vma_chain *vmac; > > > struct vm_area_struct *vma; > > > @@ -3213,8 +3214,12 @@ void rmap_walk_ksm(struct folio *folio, struct rmap_walk_control *rwc) > > > anon_vma_lock_read(anon_vma); > > > } > > > > > > + /* > > > + * Currently KSM folios are order-0 normal pages, so pgoff_end > > > + * should be the same as pgoff_start. > > > + */ > > > anon_vma_interval_tree_foreach(vmac, &anon_vma->rb_root, > > > - 0, ULONG_MAX) { > > > + vm_pgoff, vm_pgoff) { > > > > But vm_pgoff would just correspond to the start of the VMA, not where the page > > is actually mapped? > > > > I'd assume you really want the linear page index of the original page? > > Right. I've reconsidered and realized that using vm_pgoff is indeed unstable. Your email client is inserting (kinda) HTML :) & apos ; -> ' please tell it to behave :P > > My initial idea was: as long as we can find the VMA that maps this page, > it's sufficient for anon_vma_interval_tree_foreach() to check whether > "vm_pgoff <= pgoff of the original page <= (vm_pgoff + vma_pages(v) - 1)". > > However, the flaw here is that the VMA may be split(e.g., due to madvise or mprotect), > causing vma_pages(v) to change, thereby making this condition no longer satisfied. > > Indeed, it's better to use the linear page index of the original page. Yup :) Partially mapped large folios would cause weirdness also but KSM uses order-0 right? So probably not a thing. > > I'll send v5 to correct this. > > > > > -- > > Cheers, > > > > David > > Cheers, Lorenzo