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 A98703A6B94 for ; Tue, 7 Apr 2026 09:39:52 +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=1775554792; cv=none; b=Z5Cq823zdyrGJzI6d8qTg7QQooEnilM5ibGaE+qAGa5as7J66fIGKIJZj52th/e+WADR6F4oaNqcXKvyAemP+Sg6tNeScT3nDZTIVpv6T6JaFbCLXht0ZMsqg17J0qbWN8pfvvJIt7t0o/ShfBtEFLFVYF61je+Eftkx/gxgGqs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775554792; c=relaxed/simple; bh=odGMnIpFBMdOZdkEpcy186hS4VP32vzK5H0CJz+s7PE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mwPatoQTLIbxMwXsfiY+kWbcOR3L2YHXpvWfJ0uJs92/7rKOPMth54oClIyA+5wmSJ7jHUm3+4Ie5zbCnqgOnrQEeRGCCIzWCoe8czkxfe3UxOPEzzKfeaRryF3Jo8N/KyCTq8RYp4nZmfbMU/YnJJ3+arN36V+/qUVuCenABfw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j72U/l2j; 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="j72U/l2j" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D637C116C6; Tue, 7 Apr 2026 09:39:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775554790; bh=odGMnIpFBMdOZdkEpcy186hS4VP32vzK5H0CJz+s7PE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=j72U/l2jUmzGvpg2idJuL4PbKxM4+5Q9aym2tM9e3zmPkOLSPu3JVlRSixrkmfzff n3Rv8L9ZwpxZHY1d6JYbazSRbYaY4ABQabk07Ljj9a4G4/7BdT+8pm/OxVPIRAi8xe 04dpg+T2rm/fQzaUXZ5FuCbNL9AhfNQQXLwXJEFbvkXLjWEv0HvPHn2YYg8KFNr9pg q2TyE3FtFQmGfO3K4HNFMlCweRvASR/QrmaMHIqcMAQRaA/maajCJOKtphFiAzWbJ2 tObNaW9JH77bk4FsSaCIizJ24kQ6SgPoBa6MUc+z6dlOyR6Ni5OM9h0Kud0IAC2OFF AVJumIve+vHBw== Date: Tue, 7 Apr 2026 10:39:46 +0100 From: "Lorenzo Stoakes (Oracle)" To: Hugh Dickins Cc: xu.xin16@zte.com.cn, akpm@linux-foundation.org, david@kernel.org, chengming.zhou@linux.dev, wang.yaxin@zte.com.cn, yang.yang29@zte.com.cn, Michel Lespinasse , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 2/2] ksm: Optimize rmap_walk_ksm by passing a suitable address range Message-ID: References: <20260212193045556CbzCX8p9gDu73tQ2nvHEI@zte.com.cn> <02e1b8df-d568-8cbb-b8f6-46d5476d9d75@google.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: <02e1b8df-d568-8cbb-b8f6-46d5476d9d75@google.com> On Sat, Apr 04, 2026 at 09:44:14PM -0700, Hugh Dickins wrote: > Perhaps there is, or could be, a cleverer way for KSM to walk the anon_vma > interval tree, which can handle the mremap-moved pgoffs appropriately. > Cc'ing Michel, whose bf181b9f9d8d ("mm anon rmap: replace same_anon_vma > linked list with an interval tree.") specifically chose the 0, ULONG_MAX > which you are replacing. No, I don't think there could be, and I wouldn't want anybody to try to implement any kind of remap-tracking that might clash with my future work, not that I think there's a hugely sensible way of doing that with the current anon_vma implementation. > > Cc'ing Lorenzo, who is currently considering replacing anon_vma by > something more like my anonmm, which preceded Andrea's anon_vma in 2.6.7; > but Lorenzo supplementing it with the mremap tracking which defeated me. > This rmap_walk_ksm() might well benefit from his approach. (I'm not > actually expecting any input from Lorenzo here, or Michel: more FYIs.) Thanks :) Maybe I should go read your anonmm implementation... the mremap-tracking is tricky but I have it working (modulo, KSM, yeah this whole thing was a good hint that I need to look at that, too [+ whatever else I've missed so far]). Bandwith is low for foreseeable future so expectations of not-reply are probably fairly valid atm (and yet here I am, replying :) > > But more realistic in the short term, might be for you to keep your > optimization, but fix the lookup, by keeping a count of PTEs found, > and when that falls short, take a second pass with 0, ULONG_MAX. > Somewhat ugly, certainly imperfect, but good enough for now. Yeah that could work, it's not likely that many of these would be mremap()'d right? Yes ugly, but anon_vma is (very) ugly. Cheers, Lorenzo