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 5E96FC3ABC9 for ; Wed, 14 May 2025 01:23:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25C9A6B009B; Tue, 13 May 2025 21:23:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20CFC6B009C; Tue, 13 May 2025 21:23:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0AEE66B009D; Tue, 13 May 2025 21:23:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DE9566B009B for ; Tue, 13 May 2025 21:23:23 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 1215FBFD1B for ; Wed, 14 May 2025 01:23:24 +0000 (UTC) X-FDA: 83439765528.27.0A0E401 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf30.hostedemail.com (Postfix) with ESMTP id 14DB580007 for ; Wed, 14 May 2025 01:23:21 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DiCHsloT; spf=pass (imf30.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.48 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=1747185802; a=rsa-sha256; cv=none; b=V+qTVQjldcWbBxWSvP0Qx6t66721aBwxl6f5Vn1kxqDkLPc5iIqacCMcx0jyIdbyv4R58J r0FD5+Us0ZYOK4rsdpaQ+X4vNisvw33M8WThdGMuik7wnmxrLDAiGgTHFE3VSo3KawsLno 7gL4ib/qghaW0Eo24f9Ocqp0p7NpgyQ= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DiCHsloT; spf=pass (imf30.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.48 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=1747185802; 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=7KJqnmqdkJ2yVjjwm6trmjkqceHP1YPoF0Zpn5WkZuE=; b=SijXAaqMDe2viIIsAVHu91rRF944sjfl0Oxeg2JvQe2dYRY4ZfCcoJ6wqaF/JVlpeT+JRQ q3bJsv+Z5C2/CumdG9wmqkWCx/6BKkJpK0p2qqCiywQG+LKfN12MRAiWElT5bQZVshVtxJ MMeeIoSyjyogHlnTMVS4Rflimw/u7K0= Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-5f3f04b5dbcso10006132a12.1 for ; Tue, 13 May 2025 18:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747185800; x=1747790600; 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=7KJqnmqdkJ2yVjjwm6trmjkqceHP1YPoF0Zpn5WkZuE=; b=DiCHsloTlQVnuVN/GsHlH6ogmGESFreycKs8bX8MYWJlWe6vB5DVxF8hFY3Mzq4+mS eHTMGCpGJ2W832b7ba8yd6a231gN8Jz7TXCEFKxVjvG6nCUi4LrNi0x0yiv+oFAn8bzy 7XL2/Jx1HBrRgAJj8wZc7+tlnQdi1TBNT6c3OeStkJrN+feJxRqxSgz6AP0Sw0O4Ci90 5v5swtr/4uSqdOgb8VdJJ0AKQEjiIep2Mc4ITMbYLfkG5f9JNs/RWetjGsuw7N0MMVBL uUJnnGeLwrgE24iCg13No1WZ7HYwR6Cxrz/rMoq8VkdHL0KAmQzP/WbvKBWqeap/+7RS Paug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747185800; x=1747790600; 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=7KJqnmqdkJ2yVjjwm6trmjkqceHP1YPoF0Zpn5WkZuE=; b=K0PW9RejAigOdcc4Ctugo3lIgIJoZ0pq4XtQUhcRRaoYTv53SBiYFBsANePi/pen1F iPlliljKvwFr+usNBiPoSOWUDL267V9IjZDdtaZH0f4cNRfbxiGB2Bx/+7GeVcx8NTQn UaAxGQcDtwufJZaR0t4YtwiXOighmYqlLshz5QG3/7zx8ioRbFygO0kkn1lsfbdPPZjc X7pxatp9he9JiEkHm8YQA3KfBgyky4JnmgMJAm2ZXrX7iCo24kLq2OpTEZeTKG3JwQNk xTxyml0cBTM6xR3vpoDYk2r73giWvj/Zc/8kBc4LRlkx3TZ1VOkOtix7XEO3F3zsOVrn x4CA== X-Forwarded-Encrypted: i=1; AJvYcCVzouJ13Fw9h9FPudbv+lDZiM5XTfbdum1cnnEOfns6iMQYeagH+Usl4lAojkPVtA1zgkc12uQb2w==@kvack.org X-Gm-Message-State: AOJu0Yw1AXpeGSw+nBZMR1oGxsjdmRD6XmVYOSvGq3DgS0WHI2m2hKvT +/oM52Llh8PpeofvtyVLWTPGnUvYzFCVtNjukPbgpaF0ANFhQ7nS X-Gm-Gg: ASbGncsRdF759RWyOQxhUf8IlKz7NnM2hg/Xb1xTRuYSbKi30UjJeSHK3yafyGcKBC+ kQYy+U5HwnjyorjFOHfrLEFaYHUplf60YEU3mQH2Lp0iKe0AGWxlc9MnHmsw2Czz5EeAlRTEDla n4l+W2rDiffxtXHvzzd8lamqACmD0lq0Pp0OT18XRQNUJ/Af+wPq0PO5vmoE6bvu8HR9+eDNXAt lYZUdFQg03hXV8fUxJ85fhZdb2wJCJEeQDLTJBmU72bgL1+TDk8kt56POrr9SX8BxaPax/C3jd1 tODVYgj3o30adA1pvlzDVRI08IcjguDyMSlhBk8H6cevRGt3L0I= X-Google-Smtp-Source: AGHT+IHB04dZlBTYAbPkfpeObG0tCs8zqy3DaPkaIcimgdIPVhe+rPPNt5KBZNlE9uCiMIeeQg24Kg== X-Received: by 2002:a05:6402:2103:b0:5f6:c4ed:e24e with SMTP id 4fb4d7f45d1cf-5ff988d44d2mr1057048a12.27.1747185800231; Tue, 13 May 2025 18:23:20 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5fc9cbe496asm7954934a12.6.2025.05.13.18.23.18 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 13 May 2025 18:23:19 -0700 (PDT) Date: Wed, 14 May 2025 01:23:18 +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: <20250514012318.2impqotf65p4ihsc@master> Reply-To: Wei Yang References: <20250429090639.784-1-richard.weiyang@gmail.com> <8c268ece-71a7-470a-bf8b-71d3e4920977@redhat.com> <20250429235608.yvbcxybkfsmp6ow5@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-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 14DB580007 X-Stat-Signature: 6gk61o5scs1fuozjggos9d6wypr1wjnb X-HE-Tag: 1747185801-83411 X-HE-Meta: U2FsdGVkX1/pX9IGC9B9vajXfzEmLHmdi7U0SJJ0C071jLVQxgexL/nuMqbaaaheqwcx3d7VLCnZk8OvesDF4s/50XBMcfg2sCBanxyzR51RNPB6M0SF9gB9OKI/wQqzyFsTD8qFHSlHMBVPt1pKBqvCLHoLVYXz6dLmitY9/XhCfGo5LHhz2284kYj20BLUM0KR+p6PXwcKqxiUaRtLtLgO/TtCGBBT/TfbhUlIWVI6lUBPiQXZH5Ck4PEs2NOt0bW023kLeDoB1Qi8ueYzFmTJNTdgu3184tT18XPLHIubMfejntrXr+o85NEC55Kr6Bk96TfsHkDe7P/ViiiwT4pLd7OnevHqsv/qFM2f9WQ+LmoFsMlxVSVDe/4x61ywqvHNeXT/EI53vTU+swXgXhtN6b+GEN6NCuBz7nkMlgPMzigD6YxMfNdVgQIwu95HzJC1cEjcILEor4trXLTzX4olzXfe23heVM1MDXOlMJA7TXnAoH/d4CoSmqD4gd6EtTy4cmT1fF3spQdN1PmTCBWBqxoh25bLq4N8rw9eD5u1g0hZ4pjaXjeN+h5hLkvNO6QSZ/8jWHaBIB4WOaY5jx45cItzacAwtl/0SRmnoTXST8bAl8IQaMc5Daq+1v7JUWvIeT0iny/lvbR/fH2lH653ldu9OozwWjNMjdTGZGNYDrrXwton+HFoDM5IEImuTNVe1gXSwgDlpNcqBx/tCElJSpwbHPvuV3yj3Xs4bvvfNOPyay5/G5ExFhMCjBxQvXKKIe13/l4eVzU3koAI6j3XheHlS05wxa8SRQ875Ry73NNRsZ2e0GuFAPTAe7MxEWgMiquhsPedIT2fyhAergYJwiByg3HGclObCcNs6rcJNbgK0lPBvmSr3MOhiQrahFLFcny3RaOOiG1YODIP6Hymfg72UYwwxulvq1bAYuEmcMmpUfnCrgQA41lFjWwLdaBY5bpHdNSo1xVJxtY RoRIqJu/ sfbY3MapZ+gR5eFiXN4BEbjugFdpGchHcYk7TQ9DUhQvUIrwt4iJDzFci714KPIGqKovDUTAW8oy46N2U3pqFT5djmQdJbp1QpRwsAPdnpYiaiQVWndvnueb0uE65BbXa3pgnr8+FkcNbESNGIPLVChR24B4tLMn5ULmnJ9z66niazxjxqib+AUGIM3S7ryIRk1Xgn5j1ajNwVu17KuDt30WTk+1v2rkbiMCH+mPf/d6jwc0VvNYbdW72Hjvjs0v4utWFhtocoy2B/r0R5kdd/thjBajMUv1cBbzTMSYSpEM91ok92JD1rkR/6YH+mx1fXid7ua10b7sHwOB9r7jw+GeejAd010n9wx553UhtMp8d/THgTzK5s9vYghUjrxl+foSrFlgF7TGVsJw6D5mROt20bw291g8fEl1JS6onAebpGosJHnsmaFpfp1FwNkZaSghgM3wz86L73BoLQ7IaZMWqMNrV5SAVCJinjVZQq/uxhEK1U0Iw5ka6uNHz7id1v0jNYnl7CowCMgyOy+3LS48c66xbfI8ZNvMZmhXW3X6/ooLsM9EsntoRw+KfPpv1WbARHl3yZvGZOoqIcrQAlqaxKO9zMtJUXWrbdX9qTMRKIdG4a3I0W17lQnjGhFUQeAAetzok0GZAWwGLDy99QR7L/sDWTApnEjQlCOX2FKlBWmNPt9ZatUnSIjPHlXNbpduUH8v77OhqOk3GF/0w5TQpmQ== 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 Wed, Apr 30, 2025 at 09:47:16AM +0200, David Hildenbrand wrote: [...] >> > > Agreed, skimming over the tests there are some nice diagrams and cases. >> > > >> > > But I would hope that for most of these cases we could test on a higher >> > > level: test our expectations when running real programs that we want to >> > > check, especially when performing internal changes on how we handle anon >> > > memory + rmap. >> > > >> > > E.g., do fork(), then test if we can successfully perform rmap >> > > lookups/updates (e.g., migrate folio to a different numa node etc). >> > > >> > >> > That's a great point! Wei - if you could look at making some self-tests >> > (i.e. that live in tools/testing/selftests/mm) that try to recreate _real_ >> > scenarios that use the rmap like this and assert correct behaviour there, >> > that could be a positive way of moving forward with this. >> > >> >> 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) > >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 ? But we need to enable pageout in this way first. I am not sure why this one is easier way to test. Would you mind sharing more idea on this? >Some rmap tests could make sense for both, anon and pagecache folios. > >> >> Something like below? >> >> * fork and migrate a range in child >> * fork/unmap in parent and migrate a range in child >> >> If the operation is successful, then we are good, right? > >Yes. And one can come up with a bunch of similar rmap test cases, like doing >a partial mremap() of a THP, then testing if the rmap walk still works as >expected, pairing the whole thing with for etc. > For both way, we could arrange all those scenarios and also do partial mremap() during it. >One "problem" here is that even with MPOL_MF_MOVE_ALL, >move_pages() will not move a folio if it already resides on the target node. >So one always needs two NUMA nodes, which is a bit suboptimal for testing >purposes. > >For testing purposes, it could have been helpful a couple of times already to >just have a way of migrating a folio even if it already resides on the >expected node. > This looks we need a new flag for it? Here is my plan if my understanding is correct. 1. Add test cases for fork + migrate. We may limit it only works on machine with 2 NUMA nodes. 2. Enable move_pages() on local node, then remove the test limitation 3. Enable madvise(MADV_PAGEOUT) with multiple mapping, then add related cases 4. Add mremap() or other cases In general, to verify rmap dose the work correctly, my idea is to * mmap(MAP_SHARED) * write some initial data before fork * after fork and migrate, we write some different data to it * if each process do see the new data, rmap is good. Does it sound good to you? >-- >Cheers, > >David / dhildenb -- Wei Yang Help you, Help me