From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 AEB552DF68 for ; Thu, 23 Apr 2026 20:10:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776975038; cv=none; b=QaO/uqAu0sp2+qjlDXydYLTVV3yOiBtmXT+Rx7zmEzG74c+6DaGStGOsgySJHeFYL3j2KDbIAuKIs58vdzBOuP0mYCuAqCRdnoJRQf1GcXbE6ohudZ9dC6H+8S9fcLl71QfjXp5Gb8uMqD33zHhVOW6zOzba92xJdfq8gUekk4U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776975038; c=relaxed/simple; bh=HWvc3SolTkjILjVuQingZd/cQ6XMRPtVQk3Bexw8POc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=snTXeRvv2/HacNaNZTkWgJu9VgHBijY2Sz0DF2+2m5y0YAVNXfTzPgmfrXu9wIYRJSMmIoObCoDDx7iFGScNTsPc5X9ahyLkvDV3i+pYJOo6cPjCjJhuLNGG3/FNd5OXdJsKffHOWg3UTdhTl6AJTLuDlwpai/1AnHMGZ0G1D3g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=fqOYBuwo; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=uIfRLiTC; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="fqOYBuwo"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="uIfRLiTC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776975035; 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: in-reply-to:in-reply-to:references:references; bh=L1G8kt4KIcRoHxbZhKFDwigWKJXLBw/Au6uDx0Oi0Fg=; b=fqOYBuwoG+TkPcby7u/3GnKy6aC+oxzmGZgmhLmt4XIznylsVC+kR4aNZDHRYy9iV1J3LS 2RVfJaFMhaRTGUv6m2/WJFaHelrUeecw7kEeVSQPzljRtPMVJJugYw3Zq1LfZipGEh8xbl gtvBFAr1RPJ76FovSeetfgJ7gzpSWA8= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-453-To5wons4ORif-YtJmNMDzw-1; Thu, 23 Apr 2026 16:10:34 -0400 X-MC-Unique: To5wons4ORif-YtJmNMDzw-1 X-Mimecast-MFC-AGG-ID: To5wons4ORif-YtJmNMDzw_1776975034 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-8d3ea68b9cdso1383232585a.3 for ; Thu, 23 Apr 2026 13:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1776975034; x=1777579834; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=L1G8kt4KIcRoHxbZhKFDwigWKJXLBw/Au6uDx0Oi0Fg=; b=uIfRLiTCfJA0XH3cVVfxBGtSRk78RR9/pGET5yvBE1xAZGMOe+JfXigqRPHWaUB3wh t8w3bJnlIX9FKxFprvDfJ5sN5rvf9l3raPfP8UFyI3k7adcS39wB+I4djBjUTWS8pn23 pJ+M04GcyseVtZHuqJ3FY6umojVzhu5L/JkHKUje14BQnbmQdrDNW7a3C1jZUTsOnJGC PCBEQdsewKBVA6dzTcHGsb0CDBCD8leuUWoqJAnD4FH2x4CVLaQMDsYZqoYHpVO7TlrQ LssGP0faSuzyn6Ite29VecxdD5i3ttUL98+q+b3gp3dVU4k/xzys/0JuY0DJI4JnuxCt tTsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776975034; x=1777579834; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=L1G8kt4KIcRoHxbZhKFDwigWKJXLBw/Au6uDx0Oi0Fg=; b=aT0G56454dT972BfqROAMY/NGTk6bF5WIpGWm4NUE5JvOP1F+zPBI/TVmGph1x20bN dKMYxo/PnD5VpWUI5Smr2XzIW3dKS6KW29YI8L7WzFH/spRN9sN4vCwhd2Ln+/2SKE90 icAXgG3cIgGvbPqy2s4IODYE0naOLUr8D/s4DLQPGuUEOPJ9CTduYsblij9GlAnMTi94 1vt/XcSlyXeCoziturqpAGjANMrfne8m5Mzt/yNpLT8biP+ImUxpe1hoIhP0C+Gqg9Wb YZNwZmRaKPffA50Onn800RRjiZZ4y+bP1Ikbrm8z3TssZJnaVq2mp/6GfqJ2cqeJiT1Z Wcfw== X-Forwarded-Encrypted: i=1; AFNElJ80EyW8TTJ9CR9pfm9lKLhvZJT7moSP2e4T1IQQ07TIgBWagJuuLD8Fnk3DkVfPMzIBTmLQjIHVr3/2hdo=@vger.kernel.org X-Gm-Message-State: AOJu0YzFPMUvGgQ7bMWgl9mBXXfBox4fWx3lqZkCjXmWxlPf5ox14peD qwBSCR/rE30+cgaUGHYCjAi9Cg8Sk2zBD5d5c2AwfMESnfgjtU5k0cpgn7+FtkK8o+n+lV983zR HL71UhexjelWBeFV1sJS9NlBWXXtZ09yuvrPKl6J6/A9rIz1w1CNxGtYgYWKCs3uNZA== X-Gm-Gg: AeBDiethWXqLerJPx3xF0Ts8MJod5SsTLbyiXQGEWpav8IrVv3La+fPNtgMSE/u15LC dkJ2WpEwJkWdIp7nExssrizJCCYQSkYmIht3Uzpd2TQpNJZ9CG32ULcl4im7wY70XyJJJsiXRvJ N3IHDLrn+W5e5wxDtmiFOgXNaKsSLEVAOOl5F1r0+KC1aPUkZRADJ3G55ShaK1uY8h9VOijoDJd 4PAMCNPl8jRNGpLw5LmJKeQd2b3davVZIYTB87v5Pub+26iaUwfACoYNdMmh+0+kvgkTUm+Dpf+ FYn7+MdHFwGILsAKJpNLvOsF9FUJr3W0jriymNmwTqZMfI4D3oL/2Y+yPZ5mKPeel7wUvUqi9kh DHtS+OtVnV1+22lWWcs6QEK1JNID04aiVIxEFKzEryx72t0heQN1vqa7iIA== X-Received: by 2002:a05:620a:25ca:b0:8df:1541:d782 with SMTP id af79cd13be357-8e79236e338mr4156918685a.52.1776975033993; Thu, 23 Apr 2026 13:10:33 -0700 (PDT) X-Received: by 2002:a05:620a:25ca:b0:8df:1541:d782 with SMTP id af79cd13be357-8e79236e338mr4156914485a.52.1776975033492; Thu, 23 Apr 2026 13:10:33 -0700 (PDT) Received: from x1.local ([142.189.10.167]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8e7d8edb789sm1845246085a.31.2026.04.23.13.10.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2026 13:10:33 -0700 (PDT) Date: Thu, 23 Apr 2026 16:10:30 -0400 From: Peter Xu To: "David Hildenbrand (Arm)" Cc: Kiryl Shutsemau , Andrew Morton , Lorenzo Stoakes , Mike Rapoport , Suren Baghdasaryan , Vlastimil Babka , "Liam R . Howlett" , Zi Yan , Jonathan Corbet , Shuah Khan , Sean Christopherson , Paolo Bonzini , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [RFC, PATCH 00/12] userfaultfd: working set tracking for VM guest memory Message-ID: References: <34f75083-29a3-4860-8a6e-94551d37ac6a@kernel.org> <17b0dc02-eee3-46d6-9afb-5f81a3a20216@kernel.org> 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-Disposition: inline In-Reply-To: <17b0dc02-eee3-46d6-9afb-5f81a3a20216@kernel.org> On Thu, Apr 23, 2026 at 09:25:30PM +0200, David Hildenbrand (Arm) wrote: > > > > The other thing is, as I mentioned in the other email, I still don't know > > how the current RW protection would work for anonymous. I don't yet think > > the user swapper can read the anon page with RW-protected pgtables. So far > > my understanding is maybe you only care about shmem so it's fine, but it'll > > always be great to confirm with you. > > I wonder if uffdio_move could be used for a swapper implementation instead? If RW is justified to be useful first, maybe. I had a gut feeling Kirill's use case doesn't use anon at all, then if nobody needs it we can still decide to not support anon. > > If we ever have to read from a protnone page, maybe we could teach ptrace access > to do it, or have something that can read from prot_none areas -- like > uffdio_copy, which can write to prot-none areas. Somethinig like swap_access() in my proposal can also partly achieve that. https://lore.kernel.org/all/aYuad2k75iD9bnBE@x1.local/ There, it was only about reading from swap so far, though. But that one might be easier to be extended to read PROT_NONE and directly put data into buffer user specified (ps: in my local tree impl I named it maccess() to pair with mincore(), but it doesn't really matter; it doesn't even need to be a syscall..). To me, the interfacing is not a major issue. The major question I have is why RW protection can help in swap system impl when we already have uffd-wp. So I want to make sure the use case can't be implemented by uffd-wp already. Because that's really what we might do for QEMU. The other thing is I want to see possibilities of reusing any new kernel feature that can provide hotness. Currently idle page tracking has issue, not only about perf and rmap, but also on not working with mglru (defaults for Fedora/RHEL). If we can split the requirements and solve the hotness issue, then it'll also be very helpful. Thanks, -- Peter Xu