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 ABCE7C27C79 for ; Thu, 20 Jun 2024 09:07:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D2206B017E; Thu, 20 Jun 2024 05:07:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 382066B0189; Thu, 20 Jun 2024 05:07:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D5A16B018B; Thu, 20 Jun 2024 05:07:59 -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 EC6836B017E for ; Thu, 20 Jun 2024 05:07:58 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 97B7F1A0393 for ; Thu, 20 Jun 2024 09:07:58 +0000 (UTC) X-FDA: 82250689836.28.E33A5C4 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) by imf26.hostedemail.com (Postfix) with ESMTP id BD0CB140012 for ; Thu, 20 Jun 2024 09:07:56 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OrxGHBaE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.219.52 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718874469; a=rsa-sha256; cv=none; b=DbHKlv29CHEXO329JtSFpNRbEy8eNk9YQwR1T36iO2l7Zo4+1nQ6eFO9H059QQERq0X/bz Kb2mEp+XgEwPx0q3J2p4r0UcN5Nv17QeAdPDTX1dgrC3dDlys6GVwvs/9PFtE98nBz+7hi LKWjtlAQbN5YJxQ/+/8CK8Z63QL7WEM= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OrxGHBaE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.219.52 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718874469; h=from:from:sender: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0GXkSpyAxHVXjooFkN6SNvji1ikpv4kKnA6SYohOUIA=; b=y2JQA5MBT/mgn4HkOKChc4OaCkf274JuuCEoSQuQYRAftnYvC9Yi8sQl6fqE5r4LbWlAM+ EPaq745dApbdDk8T6SS7jb19PvWCWrm3bp5DPuCEVKOf7vG52nzp+ODtR0JhwMkdCUhmlg GNCgqdTe8aPU/x/IlW7pnuhk6Jh6YYA= Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-6b06bb80d7dso3459566d6.0 for ; Thu, 20 Jun 2024 02:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718874476; x=1719479276; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0GXkSpyAxHVXjooFkN6SNvji1ikpv4kKnA6SYohOUIA=; b=OrxGHBaEfayMvBnU4/HPcD6awzdFHxadNtXEYVBaN4MEGshMh2ktBCDAoF2k32qmT/ VvDEpDjar0bkQHMF635N5Q1LqLkypXUEiyXrnfPxk9uRTACpXJ0LNxjAJ1th5zy9/z7h iMqOIclnqAMwTqIR4WWZA7677YjsaWQMi6ee+gv/CgGkH6NWxrAxRqAjvwWWhBfSdCqt 6WjKWPKQ8WXSJBf+JSFSIvDijTKfdfjioK69GgjYALE9HDGeztx72TKFgGFFqXWo2O9Y S7kmGP2ZyEGaFnEe82PE3UmtZyj5+dZGG50kDBtErt13JbqCDtgZ2zqWe4sVndFx5hbe K7zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718874476; x=1719479276; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0GXkSpyAxHVXjooFkN6SNvji1ikpv4kKnA6SYohOUIA=; b=YIbeo+SI1teL9KU5hBYDCT4AQDNJdtCTk+beezdEFni/+5PDHZtWJ6tTtL8HOgqOvg y5iYmjZD3yqrkmdgSl7vTTqnmgRldPgK1QHiZ+V6U/eG7BzWiY9Ygc3oZZFsbyBzcFhh +XuTWYSVvMnNHw+gySQ7l8l0QXUH386NQy3cYmBUuPV9+uM0Ne9w748E4vDgDX9ar7zp t+PJ1C5/Gj+69/gxFC52XuMKJndJhJSnYJZPe5fuGWEjvcaGzPY8VUD25DF9Ham9IGyR WpbI2jmv9XEn9EJDiqvC441aCMm5KvwNyMLRXLCkhbesM/JuLtH5SRx24QInOp5kC7km r0Ug== X-Forwarded-Encrypted: i=1; AJvYcCXVX7zNlGDwlxbgyeWUIusN7L8U3bm5pnYoyieFdayJBLljzdid56a+37WT917a17CPq3p3TON3cRXbgBJCwuoTsYU= X-Gm-Message-State: AOJu0YzMUXlGQ9jEpVL+KqPaCAeNYiRp0Sxdm73eAlXBl67H/shp26N/ gshb/OPpaJRL/FNACT709lD02O/DIh6YkQIv0jsIf010LvcBiw/BNTIaAEFAg+6UlVtwycp/P1Y rzoFE9T1ySmx8958IYiJ8Vzd8+Y8= X-Google-Smtp-Source: AGHT+IEb38tAo1sA/ja0PtXWy2Qpdz/CYU4eKd/153tUBxJT/fECGQpUyIekCxfR6EYh8mj/WrWrQS9Vecr6W3zq71c= X-Received: by 2002:a0c:e14c:0:b0:6b5:420:bffc with SMTP id 6a1803df08f44-6b50420c082mr38186496d6.29.1718874475620; Thu, 20 Jun 2024 02:07:55 -0700 (PDT) MIME-Version: 1.0 References: <20240620002648.75204-1-21cnbao@gmail.com> <87zfrg2xce.fsf@yhuang6-desk2.ccr.corp.intel.com> <87o77w2nrw.fsf@yhuang6-desk2.ccr.corp.intel.com> <87jzik2kcq.fsf@yhuang6-desk2.ccr.corp.intel.com> <877cek2gf9.fsf@yhuang6-desk2.ccr.corp.intel.com> <8734p82f61.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: <8734p82f61.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Barry Song <21cnbao@gmail.com> Date: Thu, 20 Jun 2024 21:07:44 +1200 Message-ID: Subject: Re: [PATCH] selftests/mm: Introduce a test program to assess swap entry allocation for thp_swapout To: "Huang, Ying" Cc: akpm@linux-foundation.org, shuah@kernel.org, linux-mm@kvack.org, ryan.roberts@arm.com, chrisl@kernel.org, david@redhat.com, hughd@google.com, kaleshsingh@google.com, kasong@tencent.com, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Barry Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: BD0CB140012 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ntn8x1i9qso3rzsnscuopt96mga4uyyx X-HE-Tag: 1718874476-898328 X-HE-Meta: U2FsdGVkX18kuXIMrBfQwYMVlQs7GQFyhmWGeSef9E0H23nPKre63FGxfpiUiPOJXT/qDFlC2ak6CzvxzjoWD+uXzwVHNgDxTGgcvJcQztckWb0plTtvNb12XapEVmMHxkAzqOwvdue4RjUjbzuKxv0inW3VswU30dwihL9PkX1L44sUeupXv5Pat4zk9q5E+1nvHJOYWJq2MIhbCZjA9NDhxfy/KewheIBr/yJfrEZg6a/9JGW3aZVPUB0d8kxXzDDrSYaMz/jW5QRteVkZSOeWv+WmYpUDlUFy46rqhfWYAlWbuobED2jOmE+T8QCAe0gsr+ck2ra7TZZNin1NnkrP2vDYt41f+7+5vbRz0512RpJeq+k2DvvJu0eTIZ/Tq5lghxP5Sqvdi38bzD+UGkTzhCsh5vnm10Zup042nVBjMi32P+uAtF9mPfdFwId/pdbAzmld2edbYtCzH8s/N2LwcgBFrMrQGJn/8Z1zQqT7hZtIDZO7eVW01/bz5at/e4VX8TTGlF2eAzA5LmaZ+ed5lGMfFGQTK5MoNeh6NxO9dXyS5k55YTSBYEWitXBp1NE3hkDqM/OkFJPaaw8zenjByINpCZKI57gAqc92tdvOFLd92zJyZrsY9m6152jevmheQ2UN6x6TJc8qhUWh5V0kk9wIXEXsnu1um8P5hxLTbuuoO23SduDJXQj4f7ef84vg7jEX+R+lVWccov5KB4ZaD9QyenGq8rvMGL0s/eBGAetK0KhOFjOS4H6sMjzvUISHj8GGGqtWiNSHf49IC10xwvGNeE4le636/dXYU/jNWuIA7/eaBLKaJc037bSbO0JHOJsuuokb9UcHrPcCHkjsY03L9SLf0YgTt48e2ee4E63tVXaSYSjMsPc2/mcchwsfYN1hPVqvy0GVvi33VW2fTL+AAlfQYogG8qQlCePsAF5VDBB3yBPUJsDTlnAJbiaJ5COh9UGA3pkhNgA wvb+tWZg lZzpHNo3MCEUXq4PfGnwHYJiQFt7kIT8HWYoHn6Sr8NmXfPOtYoCn9H3CPr5XXWcM9bNAcmQraPtvXh5TvSxB3ao148ZN60L23I4aCNA5fGJweBZth51O5HucfTIrmYicGtfuG13zugrZwVwNXihwpxwe1phLJ52DNRetXmXGUfgo/SVDk/MIBiFTNGF/YPDeTfPqYxisJLlpOLkJtVJ/GGu9JxI/DdPkdjjt4A1deSbRDeNEebbqrTh/y/AjflxJAyKtWoNls6I+fcYy1c1Dnwt7iCMbhXJItb02U21pBQWF0yB2lrGWhD2LMXATgw/30GmxgsfxyUFDt2bc4Os46LgWOtMIX/b1crjN4FsQMgysUJs3whh40lm7n+gNiHxayz/e1J7YzUISMNaZkOBVn4N5I1vclOZmDwGp8mfd5OEG3bo82BKNJlEB9ksTfAl3Q7P+67MRb88dOdgZzL0APZ/ENJhblPeQo4nS 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 Thu, Jun 20, 2024 at 8:28=E2=80=AFPM Huang, Ying = wrote: > > Barry Song <21cnbao@gmail.com> writes: > > > On Thu, Jun 20, 2024 at 8:01=E2=80=AFPM Huang, Ying wrote: > >> > >> Barry Song <21cnbao@gmail.com> writes: > >> > >> > On Thu, Jun 20, 2024 at 6:36=E2=80=AFPM Huang, Ying wrote: > >> >> > >> >> Barry Song <21cnbao@gmail.com> writes: > >> >> > >> >> > On Thu, Jun 20, 2024 at 5:22=E2=80=AFPM Huang, Ying wrote: > >> >> >> > >> >> >> Barry Song <21cnbao@gmail.com> writes: > >> >> >> > >> >> >> > On Thu, Jun 20, 2024 at 1:55=E2=80=AFPM Huang, Ying wrote: > >> >> >> >> > >> >> >> >> Barry Song <21cnbao@gmail.com> writes: > >> >> >> >> > >> >> >> >> > From: Barry Song > >> >> >> >> > > >> >> >> >> > Both Ryan and Chris have been utilizing the small test prog= ram to aid > >> >> >> >> > in debugging and identifying issues with swap entry allocat= ion. While > >> >> >> >> > a real or intricate workload might be more suitable for ass= essing the > >> >> >> >> > correctness and effectiveness of the swap allocation policy= , a small > >> >> >> >> > test program presents a simpler means of understanding the = problem and > >> >> >> >> > initially verifying the improvements being made. > >> >> >> >> > > >> >> >> >> > Let's endeavor to integrate it into the self-test suite. Al= though it > >> >> >> >> > presently only accommodates 64KB and 4KB, I'm optimistic th= at we can > >> >> >> >> > expand its capabilities to support multiple sizes and simul= ate more > >> >> >> >> > complex systems in the future as required. > >> >> >> >> > >> >> >> >> IIUC, this is a performance test program instead of functiona= lity test > >> >> >> >> program. Does it match the purpose of the kernel selftest? > >> >> >> > > >> >> >> > I have a differing perspective. I maintain that the functional= ity is > >> >> >> > not functioning > >> >> >> > as expected. Despite having all the necessary resources for al= location, failure > >> >> >> > persists, indicating a lack of functionality. > >> >> >> > >> >> >> Is there any user visual functionality issue? > >> >> > > >> >> > Definitely not. If a plane can't take off, taking a train and pre= tending > >> >> > there's no functionality issue isn't a solution. > >> >> > >> >> I always think that performance optimization is great work. Howeve= r, it > >> >> is not functionality work. > >> >> > >> >> > I have never assigned blame for any mistakes here. On the contrar= y, > >> >> > I have 100% appreciation for Ryan's work in at least initiating m= THP > >> >> > swapout w/o being split. > >> >> > > >> >> > It took countless experiments for humans to make airplanes commer= cially > >> >> > viable, but the person who created the first flying airplane rema= ins the > >> >> > greatest. Similarly, Ryan's efforts, combined with your review of= his patch, > >> >> > have enabled us to achieve a better goal here. Without your work,= we can't > >> >> > get here at all. > >> >> > >> >> Thanks! > >> >> > >> >> > However, this is never a reason to refuse to acknowledge that thi= s feature > >> >> > is not actually working. > >> >> > >> >> It just works for some workloads, not for some others. > >> >> > >> >> >> > >> >> >> >> > >> >> >> >> > Signed-off-by: Barry Song > >> >> >> >> > --- > >> >> >> >> > tools/testing/selftests/mm/Makefile | 1 + > >> >> >> >> > .../selftests/mm/thp_swap_allocator_test.c | 192 ++++++= ++++++++++++ > >> >> >> >> > 2 files changed, 193 insertions(+) > >> >> >> >> > create mode 100644 tools/testing/selftests/mm/thp_swap_all= ocator_test.c > >> >> >> >> > > >> >> >> >> > diff --git a/tools/testing/selftests/mm/Makefile b/tools/te= sting/selftests/mm/Makefile > >> >> >> >> > index e1aa09ddaa3d..64164ad66835 100644 > >> >> >> >> > --- a/tools/testing/selftests/mm/Makefile > >> >> >> >> > +++ b/tools/testing/selftests/mm/Makefile > >> >> >> >> > @@ -65,6 +65,7 @@ TEST_GEN_FILES +=3D mseal_test > >> >> >> >> > TEST_GEN_FILES +=3D seal_elf > >> >> >> >> > TEST_GEN_FILES +=3D on-fault-limit > >> >> >> >> > TEST_GEN_FILES +=3D pagemap_ioctl > >> >> >> >> > +TEST_GEN_FILES +=3D thp_swap_allocator_test > >> >> >> >> > TEST_GEN_FILES +=3D thuge-gen > >> >> >> >> > TEST_GEN_FILES +=3D transhuge-stress > >> >> >> >> > TEST_GEN_FILES +=3D uffd-stress > >> >> >> >> > diff --git a/tools/testing/selftests/mm/thp_swap_allocator_= test.c b/tools/testing/selftests/mm/thp_swap_allocator_test.c > >> >> >> >> > new file mode 100644 > >> >> >> >> > index 000000000000..4443a906d0f8 > >> >> >> >> > --- /dev/null > >> >> >> >> > +++ b/tools/testing/selftests/mm/thp_swap_allocator_test.c > >> >> >> >> > @@ -0,0 +1,192 @@ > >> >> >> >> > +// SPDX-License-Identifier: GPL-2.0-or-later > >> >> >> >> > +/* > >> >> >> >> > + * thp_swap_allocator_test > >> >> >> >> > + * > >> >> >> >> > + * The purpose of this test program is helping check if TH= P swpout > >> >> >> >> > + * can correctly get swap slots to swap out as a whole ins= tead of > >> >> >> >> > + * being split. It randomly releases swap entries through = madvise > >> >> >> >> > + * DONTNEED and do swapout on two memory areas: a memory a= rea for > >> >> >> >> > + * 64KB THP and the other area for small folios. The secon= d memory > >> >> >> >> > + * can be enabled by "-s". > >> >> >> >> > + * Before running the program, we need to setup a zRAM or = similar > >> >> >> >> > + * swap device by: > >> >> >> >> > + * echo lzo > /sys/block/zram0/comp_algorithm > >> >> >> >> > + * echo 64M > /sys/block/zram0/disksize > >> >> >> >> > + * echo never > /sys/kernel/mm/transparent_hugepage/hugep= ages-2048kB/enabled > >> >> >> >> > + * echo always > /sys/kernel/mm/transparent_hugepage/huge= pages-64kB/enabled > >> >> >> >> > + * mkswap /dev/zram0 > >> >> >> >> > + * swapon /dev/zram0 > >> >> >> >> > + * The expected result should be 0% anon swpout fallback r= atio w/ or > >> >> >> >> > + * w/o "-s". > >> >> >> >> > + * > >> >> >> >> > + * Author(s): Barry Song > >> >> >> >> > + */ > >> >> >> >> > + > >> >> >> >> > +#define _GNU_SOURCE > >> >> >> >> > +#include > >> >> >> >> > +#include > >> >> >> >> > +#include > >> >> >> >> > +#include > >> >> >> >> > +#include > >> >> >> >> > +#include > >> >> >> >> > +#include > >> >> >> >> > + > >> >> >> >> > +#define MEMSIZE_MTHP (60 * 1024 * 1024) > >> >> >> >> > +#define MEMSIZE_SMALLFOLIO (1 * 1024 * 1024) > >> >> >> >> > +#define ALIGNMENT_MTHP (64 * 1024) > >> >> >> >> > +#define ALIGNMENT_SMALLFOLIO (4 * 1024) > >> >> >> >> > +#define TOTAL_DONTNEED_MTHP (16 * 1024 * 1024) > >> >> >> >> > +#define TOTAL_DONTNEED_SMALLFOLIO (768 * 1024) > >> >> >> >> > +#define MTHP_FOLIO_SIZE (64 * 1024) > >> >> >> >> > + > >> >> >> >> > +#define SWPOUT_PATH \ > >> >> >> >> > + "/sys/kernel/mm/transparent_hugepage/hugepages-64kB/s= tats/swpout" > >> >> >> >> > +#define SWPOUT_FALLBACK_PATH \ > >> >> >> >> > + "/sys/kernel/mm/transparent_hugepage/hugepages-64kB/s= tats/swpout_fallback" > >> >> >> >> > + > >> >> >> >> > +static void *aligned_alloc_mem(size_t size, size_t alignme= nt) > >> >> >> >> > +{ > >> >> >> >> > + void *mem =3D NULL; > >> >> >> >> > + > >> >> >> >> > + if (posix_memalign(&mem, alignment, size) !=3D 0) { > >> >> >> >> > + perror("posix_memalign"); > >> >> >> >> > + return NULL; > >> >> >> >> > + } > >> >> >> >> > + return mem; > >> >> >> >> > +} > >> >> >> >> > + > >> >> >> >> > +static void random_madvise_dontneed(void *mem, size_t mem_= size, > >> >> >> >> > + size_t align_size, size_t total_dontneed_size= ) > >> >> >> >> > +{ > >> >> >> >> > + size_t num_pages =3D total_dontneed_size / align_size= ; > >> >> >> >> > + size_t i; > >> >> >> >> > + size_t offset; > >> >> >> >> > + void *addr; > >> >> >> >> > + > >> >> >> >> > + for (i =3D 0; i < num_pages; ++i) { > >> >> >> >> > + offset =3D (rand() % (mem_size / align_size))= * align_size; > >> >> >> >> > + addr =3D (char *)mem + offset; > >> >> >> >> > + if (madvise(addr, align_size, MADV_DONTNEED) = !=3D 0) > >> >> >> >> > + perror("madvise dontneed"); > >> >> >> >> > >> >> >> >> IIUC, this simulates align_size (generally 64KB) swap-in. Th= at is, it > >> >> >> >> simulate the effect of large size swap-in when it's not avail= able in > >> >> >> >> kernel. If we have large size swap-in in kernel in the futur= e, this > >> >> >> >> becomes unnecessary. > >> >> >> >> > >> >> >> >> Additionally, we have not reached the consensus that we shoul= d always > >> >> >> >> swap-in with swapped-out size. So, I suspect that this test = may not > >> >> >> >> reflect real situation in the future. Although it doesn't re= flect > >> >> >> >> current situation too. > >> >> >> > > >> >> >> > Disagree again. releasing the whole mTHP swaps is the best cas= e. Even in > >> >> >> > the best-case scenario, if we fail, it raises concerns for han= dling potentially > >> >> >> > more challenging situations. > >> >> >> > >> >> >> Repeating sequential anonymous pages writing is the best case. > >> >> > > >> >> > I define the best case as the scenario with the least chance of c= reating > >> >> > fragments within swapfiles for mTHP to swap out. There is no real > >> >> > difference whether this is done through swapin or madv_dontneed. > >> >> > >> >> IMO, swapin is much more important than madv_dontneed. Because mos= t > >> >> users use swapin automatically, but few use madv_dontneed by hand. = So, > >> >> I think swapin/swapout test is much more important than madv_dontne= ed. > >> >> I don't like this test case because madv_dontneed isn't typical or > >> >> basic. > >> > > >> > Disliking DONTNEED isn't a sufficient reason to reject this test pro= gram because > >> > no single small program can report swapout counters, swapout fallbac= k counters, > >> > and fallback ratios within several minutes for 100 iterations. That'= s > >> > precisely why > >> > we need it, at least initially. We can enhance it further if it lack= s > >> > certain functionalities > >> > that people desire. > >> > > >> > The entire purpose of MADV_DONTNEED is to simulate a scenario where = all > >> > slots are released as a whole, preventing the creation of fragments,= which is > >> > most favorable for swap allocation. I believe there is no difference= between > >> > using MADV_DONTNEED or swapin for this purpose. But I am perfectly f= ine > >> > with switching to swapin to replace MADV_DONTNEED in v2. > >> > >> Great! Thanks for doing this! > >> > >> And even better, can we not make swap-in address aligned and size > >> aligned? It's too unrealistic. It's good to consider some level of > >> spatial locality, for example, swap-in random number of pages > >> sequentially at some random addresses. That could be a good general > >> test program. We can use it to evaluate further swap optimizations, f= or > >> example, to evaluate the memory wastage of some swap-in size policy. > > > > I wholeheartedly agree with everything mentioned above; these are > > actually part of my plan as incremental patches. This initial commit > > serves as the first step of the three I proposed in the last email. > > It will be a small test program to implement all these. Don't need to > use 3 steps. IMHO, it's not good to optimize for a unrealistic test > case with address aligned and size aligned swap-in. It's trivial to > remove the alignment requirements. I'll preserve alignment as an option for Chris and Ryan to compare aligned cases with unaligned ones, rather than removing the alignment code altogether. Additionally, it can aid us in understanding the potential outcomes when dealing with large folio swap-ins. > > >> And, we don't need PAGEOUT too, just use large virtual address space i= n > >> test programs. We can trigger swapout in more common way. > > > > I'm not particularly enthusiastic about this idea, as I expect the test= program > > to run quickly. A large virtual address space would result in long wait= ing times > > for the test results, as it relies on vmscan. Therefore, I hope we can = use real > > workloads to achieve this instead. > > I have use test program with large virtual address space (in > vm-scalability) to do swap test before. It runs really fast. Please > give it a try. I'm not so optimistic. Having worked on both server and embedded systems, I understand the disparity in resources between rich server environments an= d resource-constrained embedded systems. I'm constantly frustrated by how slow my tests run and deploy. > > -- > Best Regards, > Huang, Ying Thanks Barry