From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4751FC5AD49 for ; Fri, 30 May 2025 14:05:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D86106B012F; Fri, 30 May 2025 10:05:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D36226B0130; Fri, 30 May 2025 10:05:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C25D96B0131; Fri, 30 May 2025 10:05:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A3CE36B012F for ; Fri, 30 May 2025 10:05:27 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 3AB2E1609E9 for ; Fri, 30 May 2025 14:05:27 +0000 (UTC) X-FDA: 83499746694.07.05D2ABD Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf04.hostedemail.com (Postfix) with ESMTP id 2B48B40013 for ; Fri, 30 May 2025 14:05:24 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ANtrJ17o; spf=pass (imf04.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748613925; h=from:from:sender:reply-to: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bmWkVUok0htKsSniuhORHcLILaV0dvTlZyiaksU9iAw=; b=GKj0A5tu/M4FQaEKbpzdtl2LedTm6W18ltMp68d7Z2MyqwP5qk0d2tm++4QmCVzPLfRKJS ikGj9MyAeXpiSs02MZ1p+hjdquIahKD2Lo884NBk/QcR4/BmdszSFlam653R3Ei3vJPvks YslLQMhqPwrqLnXUeCcIqEXEWLhlNVM= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ANtrJ17o; spf=pass (imf04.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748613925; a=rsa-sha256; cv=none; b=1I3eASgyrvJl29PKRJpPCIaefaNHMF3Su0KtSCBJK77jmwy7vRJv8YsvlvT/+JVRvh4AoR mlWByciRJV1TrQ/ePdEhBVJpqS0XJ9h1mJyu/JqCrgJIenLglVpQZ6QXJs4S3/n4iTJyog LlfSKvO/DvnUXRifmGPk759hqLoBXXQ= Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-604f26055c6so5883160a12.1 for ; Fri, 30 May 2025 07:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748613924; x=1749218724; darn=kvack.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=bmWkVUok0htKsSniuhORHcLILaV0dvTlZyiaksU9iAw=; b=ANtrJ17oJnrCDi8RTsd1+lhQSjxFrCwFqi0gWxuSllZaGDes2lK+kw+P/UftNwHx0r kkI6mmS7HQm1LmJQjiQuabQ6kJLdWx7O/WN8y5rWN8+kN4uDpYv1Y+aH13Z6qyiDUV5Q 5oOgWJtdNcB7HYoOUuHfy3AMQKbn3CAMve2QHMdCwxUrwS2kvEPNmREgYj3j3Zn87AwS DObyGd+OMkQeKdYO7hp98d5oKO/JSaisejKIRSxrYioX0n/FkFZadPVaDhOVLExIwXwZ qzb2/t08tIwX4SvFEmiO0wqz410Vn4VtaeX5uxYs1YBd4tVrQo+E1MitlF5Hhao1FH3Q FX9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748613924; x=1749218724; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=bmWkVUok0htKsSniuhORHcLILaV0dvTlZyiaksU9iAw=; b=aOZrQzoCPVhOWvl0/3B+EUJvtv8QXcSY22k48+SwnBFeVPwy3htRwCf/41IDAQmAiW COu3xFK92owkc35lgOILOka+TWUoX7W+9NSNgshSuq2/QEc3YWN+UCSizChYC5ybvQeu cY17xaYNW6dbOER8TN9f2g2zx5hm09rIxhoqJkbwzfjmJk/DiSNinWeszbIm/GnHaAd+ mU3itQXQWX1u2zSCQt7qH95XjuVqPns24Qb+/8xKHcz+1TyDa2Yi+KU+7CGhZa2X4tWg 9IlIhq3xYyGKOROb4lSc57UtwOjSJT4jGhkjbFdJNa17ktpAemro7gAS1DdIK9e82Ogs mm9Q== X-Forwarded-Encrypted: i=1; AJvYcCU/X1kVQaMhiwKUz9/rk62k7LdUZwWo1Rde1a4BhQzUZuDdcvqSCrgnFliOcPQ9e+TCOZn/3V0H8A==@kvack.org X-Gm-Message-State: AOJu0YzNYfG6/6GZEjIJU8NScORby8ZaOS0D9Qf7s8fWRDtzElMeiJUc jtscvoMdfaPq/cWrlYn7h0HWIz9TXhXYkJ0ZXlV+5mKI7LZTUJLQChMr X-Gm-Gg: ASbGnct3SWI8aHBiVfoDk3YFEtyx4i/7Whfr2vVza8jQ36xEaZyvhl9fFWzjbFavQ7V 5yP75G9DgVI/W6T6ugOaiateKiWLz2c208Z20r9E7EcFsRaZojZrAvkkdJdvpSeUwK9079mRjdC NoqQ5rP9GNXOvehuh4uOp3rqZO4t5ANlue31qdDLBTkSV6fzwnKgG1MU2+BL21RFqf2aNGKhPCg a78Ve0kgm9dZK/V7WiilMVyNV6XGUnWWfmMzCJp3PvE2OIoLu/KuJIjxg5JqwbgaFbhcu/nxgM7 lKW6tKDAXFmQH0+vmI0lEfGVdaMkoZtOm8seDvRm5VxnKxqvnNU= X-Google-Smtp-Source: AGHT+IHAM508hvm7g2kr7KTw5+brwVmzHlUkXXFlJIl7KcW9RaNIk/s1W0dkSqEDo0pYwReFYxEXAQ== X-Received: by 2002:a17:907:9492:b0:ad8:93a3:29c2 with SMTP id a640c23a62f3a-adb3295e81fmr345881666b.14.1748613922685; Fri, 30 May 2025 07:05:22 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ada5dd043c2sm333380266b.102.2025.05.30.07.05.22 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 30 May 2025 07:05:22 -0700 (PDT) Date: Fri, 30 May 2025 14:05:21 +0000 From: Wei Yang To: David Hildenbrand Cc: Wei Yang , Lorenzo Stoakes , akpm@linux-foundation.org, riel@surriel.com, vbabka@suse.cz, harry.yoo@oracle.com, jannh@google.com, baohua@kernel.org, linux-mm@kvack.org Subject: Re: [RFC Patch 0/5] Make anon_vma operations testable Message-ID: <20250530140521.tnyjxdsy6qa6dokl@master> Reply-To: Wei Yang References: <8c268ece-71a7-470a-bf8b-71d3e4920977@redhat.com> <20250429235608.yvbcxybkfsmp6ow5@master> <20250514012318.2impqotf65p4ihsc@master> <20250527063428.4ykrdtive2hfnqdp@master> <40dc48f9-94d7-46b0-83ed-d3511789c15a@redhat.com> <20250530021112.6b2ldosl3hvhcnvq@master> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 2B48B40013 X-Stat-Signature: ezx31p9c61p4rn7nz7duk8mpetxoqrpm X-Rspam-User: X-HE-Tag: 1748613924-101252 X-HE-Meta: U2FsdGVkX1912QZZzy+bKh5q1N4P7/1sp6ABswr2r3yE9UXOiRnIewGYtu0XyZe8avASEuxAJhAdz94i74rsrlUx2AFbz0v8mB0Ly9U/M6d9ddVXmiwIlFyGOY0JLVScC7c+glVEoiYs75cI5u2IrhyxlGMKUYUV0Z564fcB3Wfgxv3J14qg5vHOlxkbsGizz0p6PffSjWl9zyrqpNqR0rShTUrB9XrP2/7lmgGqz0IsVJxQV1iit5c2m6Fx/v5g10Qu4zgMbUkDUOZqj9qvqH/K87VdCxDiWVcDKIR6b1n25aGEKgpxhgcXuUXowDYAbBHpc0WV81N1N2Kpfv/0oLV5l+i6j6Bml14iIxdyW/KxCyxalUgYSp1nq0eTgUM26g45fzPUwMhtA5AbU778Bf/ayfQ/QJW/07Vr+KxPLzaRfXZ35834zMFiD4pDZyHcFG9XRo/s3G4c3HBNd8XKQ6cnjmJa5FVUNtHmxhJI6zyAx91AZHxy0sd7GF7oz7b/WLCWixaTWMGz98U/yKi2ySJYpL1E2rrfBwHg3HLdzBgX33DsvVIMSKdFNfX7XpLe0jbychSsn0UDWTXu4IGz17M8B0yHLR90sHJH0SaUiINJ3aXOg6h9+QDg5+Hk4iXj4/cPJoD3OVymxFpzwt4q81XTPy93nC4e9BbQPo3lLmQcnOgqLTK7oubXISyJAsCh4Uyu8G2kwysEgiy6qlJPpO3BssOGg0lCEcagQ3sn1R671/fP2QOEPMCYwC7Z5YertDddH95oqwV0LhISxRKMoZOQ2ljTD3yTUKmumgLVeMUr6uK4jaD5Glcprdam1kzFlL5RHKpmFD1b6tgZpg0dZkgDk4z87KOaaqiy/qpmf1ZHCXrtA4qUkuppS8SWSYZnWqF3iTkRRYfamlIcucUX2xkfJ5aG1Hftf4mrPz+1FirtbETsIKZIF63126LG7tLAPRcFDQfRzxV6o3mlrTS X/Dc6vP8 wazWXFjGhoMKjQGgp5tLTyDJA95FG2YmaC2tYEk844FLGnZJ2qP69r6Gg1gZr7SV9EKm4Cj7prnrtGhVblIC7wBvQGqEUNo8rshwFSVOsDmbsdDYEjt8oh88rT1AYwTPjZ7lY9jYSyDNqUugeS3iJQwyOXL12up8i0lmj0HPR5qxBeTutmWuajwRq/6KHWq5XtLAL1sE1cQbnGhXvuyQHD0wmG9gzoTNfp7QuFSRSBe/B/g6fS7ymfkKABeyZt1Xjft7Prm0dC8tamTx0tusyNUriNaIIJ8xNPjR5+LLPLwaDt+a7ecJYD11xsmHPGYSZ+iqCK9afOqaZHsyN4JtXVrrvSmA0hwewL0/PR+FUn2/U62ntKxlw9JzTk3NWgANAAPa1TiggJNkdnf7CDPEotjZds9SwhdHYJRg60SBHg5zOqGyp5rmRp+z0kCrFfx8wYEg/RVFtKj0UWF8wo+QNspQ+7ODqqRkUrBGpTtwg2XEIGCM2oEDcWl18/ZHy8vomNcIdNCo6j+xA8IDKncHNLIOal6+TpGkhyalK8a673FauE6C3cau/u9WupwPmyRv/JREUoo5H37eZs+t67OT7GU12JDJ9q1zKhY1coLb4sZmWn5vv7k2uF4Y36JHfVVjveugpkIEsdlgahZo81gvx1H88d5aqneEFdLlT8zqHHu9t3qb18kLCHR+ALfV25YD3ZrKVV3xKTqTpHUkllKYY5vuR0w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, May 30, 2025 at 10:00:18AM +0200, David Hildenbrand wrote: [...] >> > >> > Thanks for reminding me and sorry for the late reply. >> > >> > > >> > > > > > I am trying to understand what scenarios you want. >> > > > > >> > > > >> > > > Sorry for the late reply, I handled other things a while. >> > > > >> > > > > That is exactly the task to figure out: how can we actually test our rmap >> > > > > implementation from a higher level. The example regarding fork and migration >> > > > > is possibly a low-hanging fruit. >> > > > >> > > > If my understanding is correct, you suggested two high level way: >> > > > >> > > > 1. fork + migrate (move_pages) >> > >> > Yes, that should be one way of testing it. We could even get multiple child >> > processes into place. >> > >> > > > >> > > > > >> > > > > We might already have the functionality to achieve it, *maybe* we'd even want >> > > > > some extensions to make it all even easier to test. >> > > > > >> > > > > For example, MADV_PAGEOUT is refused on folios that are mapped into multiple >> > > > > processes. Maybe we'd want the option to *still* page it out, just like >> > > > > MPOL_MF_MOVE_ALL allows with CAP_SYS_NICE to *still* migrate a folio that is >> > > > > mapped into multiple processes. >> > > > > >> > > > >> > > > 2. madvise(MADV_PAGEOUT) >> > > > >> > > > Not fully get it here. You mean fork + madvise(MADV_PAGEOUT) + migrate ? >> > >> > fork + madvise(MADV_PAGEOUT) only. >> > >> > Then verify, that it was actually paged out. >> > >> > For example, we could have 10 processes mapping the page, then call >> > madvise(MADV_PAGEOUT) from one process. We can verify in all processes if the >> > page is actually no longer mapped using /proc/self/pagemap >> > >> >> Hi, David > >Hi! > >> >> I'd like to clarify some detail here. >> >> > We could likely do it with anon pages (swap), shmem pages (swap) and >> > pagecache pages (file backed). >> > >> >> I could understand the three cases here, but for the (swap) case, it is not >> clear to me. You mean we force the page to be swapped out before migration? I >> may not have an idea to ensure that. > >No need to involve migration for that test. It's sufficient to trigger >pageout to then check if the page was unmapped in all other processes. > Here you mean for all anon/shmem/pagecache pages, we could have two category tests: * migrate and write different data from on process, verify each process see new data * trigger pageout from one process, verify each process has it pageout (/proc/self/pagemap) While one of these category is enough, right? Just like KSM below, migrate or pageout. >> >> > ... and possibly even with KSM pages! >> > >> >> For KSM, it looks like an general background routine. I guess you want >> something like: >> >> * fork process tree >> * do KSM and wait for it to finish? > >Probably allocate memory in each process and fill it with the same value. > >Then wait for KSM to deduplciate. > >> * migrate > >Yes, or instead of migrate, trigger pageout from one process, then check if >pageout in all other processes (/proc/self/pagemap) > >> > I guess the KSM duration would related to the total memory on the system. >The >> bigger, the longer. While the selftest generally have timeout setting. Not >> sure it would be suitable for all situation. >> >> Would you mind sharing more on KSM case? > >Worth looking at tools/testing/selftests/mm/ksm_functional_tests.c (and the >other KSM selftests) Thanks, I would take a look into this first. > >In particular, in ksm_merge() we can detect whether KSM completed the scan >when two full scans passed. > >A lot of that functionality could probably be factored out into vm_utils.c to >be reused in other tests. > >-- >Cheers, > >David / dhildenb -- Wei Yang Help you, Help me