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 68788C27C4F for ; Fri, 21 Jun 2024 09:43:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8AA98D014D; Fri, 21 Jun 2024 05:43:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E187C8D00DB; Fri, 21 Jun 2024 05:43:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB3DD8D014D; Fri, 21 Jun 2024 05:43:37 -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 A620B8D00DB for ; Fri, 21 Jun 2024 05:43:37 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4A9E01A0C7E for ; Fri, 21 Jun 2024 09:43:37 +0000 (UTC) X-FDA: 82254408474.04.283A9EB Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) by imf10.hostedemail.com (Postfix) with ESMTP id 7FA7CC0002 for ; Fri, 21 Jun 2024 09:43:34 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=V9w5ls6p; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.47 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718963006; a=rsa-sha256; cv=none; b=TkQ6KSbMyO1A30VXI3aMxX+ek0+GEubJKcuScFnKy9KoU8WR01ytqR99Jy/w0NR2PpxXbV ili10NJ8FQC/rITvPVCz3tJP1Z6BM+wHRZ2YQZaiE7a37GwITKn0vrY0vkwuuE1ZcCAUKy bpt3F68hbtuDXSCec8nscVl+jQ8k0g8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=V9w5ls6p; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.47 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=1718963006; 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=jqLHgiTMJFtaX6sfG34bK9oM4kNpdFNFa/14p8/lD7w=; b=e2fhSN/aF2lABoHqCUaBeypOL2bkrlA/cn5Edl6kZbhhNlQFlMmhDqhw1eOjAGMKb5/01o NaTcbEqksErDnwlwpwQFohAMpp3ovhgK9oTvdXsgtL3A04/3P4MR2ejdKlAPc0jZjYbSds GmueLe0jtq51OK+ghJA84q4X8sqEwVI= Received: by mail-vs1-f47.google.com with SMTP id ada2fe7eead31-48c4c5c0614so563168137.1 for ; Fri, 21 Jun 2024 02:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718963013; x=1719567813; 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=jqLHgiTMJFtaX6sfG34bK9oM4kNpdFNFa/14p8/lD7w=; b=V9w5ls6pYP5JJArhzbeTQzqrchi/6qNAfC9OMIpm6FimVk/uzyS+dmEg2zTqSyy7f2 UN+jfoF1uYAyDRp1cabz+6FcuPLmgSA0BnSVb0nSAx8gftTtycsi94jRZmDQwq93LT3n xUbVNXQ3XZhMVopzVuwJ6oNzdJ5RNudu5T0IUtF0V5AIYFzc8Xhj024ZhEmFoZr5Tc6N cSofFmUFvtAdpW7I0aL4FnKn1GP1PpJGYU+DoJZqWxiaO0wQWYVmhDpxGdKUBUelpjxc e7BU6itUW7ItPswwfPkZRx+Xd6sxKLpVP1UmZ7UA8EI0V9KIVJvJJ2g+Oc3cNWWN1u2C RNJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718963013; x=1719567813; 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=jqLHgiTMJFtaX6sfG34bK9oM4kNpdFNFa/14p8/lD7w=; b=AaQnWHf7DvnY9QRm+SAUv5uV3CohXU9TcHU6MkDHTrqoFGKu/uVns2n675Kjc5eG7f PQocahwBCVwUx/hWan5PNs4EYT6rasY5BsHKramqW5f9rwDdaxHlWxci4QGFcCPdk56Y IyELNpIJKwkY8bGi4vKwu0J3wkuwJVUH+IhKnPV9pPARmdzBfA3Qh7J9DS1Id7bn3NNA 3I0Po0Q3c7tlEotD+QfMVsW4Guqc8tB+rnSl8GfNfVoOF9dn/6gBlBwrKHhxu8OaG1XV npseZWxGOzU3S2jcQLQo76tHTpuSNry1fWtsw7EVtTOAfBga+pUw/BAUHdIOdX6pyF6t FR/w== X-Forwarded-Encrypted: i=1; AJvYcCWLrNo+yW+W6I6gKRM8L/d37H5wt8AqzjixstbckBvRsGkC4Egx2NU3Vw4XcO9olEG/1i7HlpAyWc7tXvxssJAS6T4= X-Gm-Message-State: AOJu0YxDs5++Zwh5LIUpP85Xy8uFe5aANNSL28VDTUai6aXrLyWNvVmy 7NjX2OgXW6jvKojiPVX9w5xvtLcZnZAHpNHtGVO/l7hE/lWFej8DY0v/afgf1r+w2XBQ/SSM+V0 A7CFIMgZMPso+denxrNS9G0lGL8A= X-Google-Smtp-Source: AGHT+IFMAoId7SY6B8VMs2FjQVmw40Rm/hJ1bVJU21YbkSpCM+udbaveFI7IM5pfBccw7MCoooc+zgTiRHPq4fDpT5g= X-Received: by 2002:a05:6102:3595:b0:48d:b0c5:7fe4 with SMTP id ada2fe7eead31-48f130e4323mr9965440137.29.1718963013554; Fri, 21 Jun 2024 02:43:33 -0700 (PDT) MIME-Version: 1.0 References: <20240620002648.75204-1-21cnbao@gmail.com> <87cyoa1wgm.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: <87cyoa1wgm.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Barry Song <21cnbao@gmail.com> Date: Fri, 21 Jun 2024 21:43:20 +1200 Message-ID: Subject: Re: [PATCH] selftests/mm: Introduce a test program to assess swap entry allocation for thp_swapout To: "Huang, Ying" Cc: Ryan Roberts , David Hildenbrand , akpm@linux-foundation.org, shuah@kernel.org, linux-mm@kvack.org, chrisl@kernel.org, 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: 7FA7CC0002 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: s4ayfkoowrkkznd1id44j3neriwer67z X-HE-Tag: 1718963014-688511 X-HE-Meta: U2FsdGVkX195AZeMCk2rhUFiP+Tu9/TvxJGs3p9+UOi29X6j/xpxzYB11FfoBK2vojMLJND3WuAlN7yPt6RjBNdMtCAJI/X+rYs77gZdzY5vDjdm3YoEnEURQZu/4v6eDMgMx0OQQ7vxdJ7UsgursQM2tckqxQkFE04GJ9ay2SHQsYPOMpOQMWjUkF6VGsj9g0qy0oKpg+6uPxio8g9gu2PRbAfCBUMo7xK8Vz6T4yJxYPLjWA9g6NOBczKN777E5RQTVXpjrSMZ3ZZlxhngrSiDH3lnyREfVkvS4FQYeQp+/ipmIOOeNUTkqDIzpc5KHU54D7HDChiMctR5/+521qH4WHqLF9P3DfCptsVelElf3PDVUqo2NgeL1Zm1QS267/izQSX4LOeH32DS7cwxTDzVnotAmlzPGS9uJDqb5KBeta8jDqGAMCC9KXDdq4AGsGFp3PMSiCK/Eo+Io1rmHKE7AYELo4c1kf2EOIgjAlDIwnYZRCZ/kwjkFBrD15j2Z61QKzzJ9KkWUtYXYWTKwrghBMyc2N3hu9/yKvB5M3gVsbJiwHJM4/LgXWF9Eng/pv9HKjrBRs0TB4kljUCltbJ7jfMeO5bUgVrMc4qRLFdY6GDgXYZ0hCfsCnxmEQjNoaxz1tWHC6wPckvNb8DZZU9f0vdkwvOApCGImWCxq3aI9iDPT4uWXh4YCZ6uxjnWBC09xhOpkBkRlTUHQEngsOOcwkrFzNYOdQl74/Iw3R7Wtbok+iWK7YaljyuOQaFjdmJNAB1/eo2ChCxhkHzle2Ct8HHq6oRS9cfXWc29IKUmMMIcbtd7rBgUUPeaQ21hqCr08FDyoVaOGZGP1DjhD4opWRv3psodFx+YuKxaGoDTfAzw8kJYr3c4Gd/Az/S6lHcQufzZPQbCHph4umXDzcCz6kozrAe8UwAO+UW25+UwwnFoqyHKeXpz1Noag4DZ/zw0gC19ueHZsJR7aK/ M5MMtvo8 pp/gRcxery2U+GINSqHN/rn1UsXhD33OQxZYbz0kOshO8aWLAuzAI0x/XG9IOBpvIQWSb1SXHGcicKe4S0HxbXLbsMercwquvjhnPzh+0q9AUUmwhboMyQ5Qd7uk0g4pQZYPymUKx5CWYcHV3plppP94+8BEqpHjpGLJThQzl6pveC/5dwA2JQ0jXs3+VVfhScx6IrYinrxSDVKMNQ3b2FeTHpd3CecwoFG8Rq7YnBuyMVeP6quy9XYJmQmpkVFgRLoTMCCozSNc0wlnJ1QW+tMKI0OBUoA2bDpZxotLPv/qOV9tdXADKygLzddrILv8ExHQkfOIV2AMlqeORIWKcClBPY3ZLxRll6HVObT81goWBEyPVc5wfCvgbHPEv6CMTX93fWGppDC4UOeFBwTEiG7DsqXn5uEQcUH4mzFjSePg4bTVN+IBRtdWgo0x80ez237mHDTkjTjDhyvvsatNzrMPjk5hWFPh6+7GBA+oq0YW7hw80KQYbT74iZKViiblhBkBM 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, Jun 21, 2024 at 9:24=E2=80=AFPM Huang, Ying = wrote: > > Barry Song <21cnbao@gmail.com> writes: > > > On Fri, Jun 21, 2024 at 7:25=E2=80=AFPM Ryan Roberts wrote: > >> > >> On 20/06/2024 12:34, David Hildenbrand wrote: > >> > On 20.06.24 11:04, Ryan Roberts wrote: > >> >> On 20/06/2024 01:26, Barry Song wrote: > >> >>> From: Barry Song > >> >>> > >> >>> Both Ryan and Chris have been utilizing the small test program to = aid > >> >>> in debugging and identifying issues with swap entry allocation. Wh= ile > >> >>> a real or intricate workload might be more suitable for assessing = the > >> >>> correctness and effectiveness of the swap allocation policy, a sma= ll > >> >>> 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. Although = it > >> >>> presently only accommodates 64KB and 4KB, I'm optimistic that we c= an > >> >>> expand its capabilities to support multiple sizes and simulate mor= e > >> >>> complex systems in the future as required. > >> >> > >> >> I'll try to summarize the thread with Huang Ying by suggesting this= test program > >> >> is "neccessary but not sufficient" to exhaustively test the mTHP sw= ap-out path. > >> >> I've certainly found it useful and think it would be a valuable add= ition to the > >> >> tree. > >> >> > >> >> That said, I'm not convinced it is a selftest; IMO a selftest shoul= d provide a > >> >> clear pass/fail result against some criteria and must be able to be= run > >> >> automatically by (e.g.) a CI system. > >> > > >> > Likely we should then consider moving other such performance-related= thingies > >> > out of the selftests? > >> > >> Yes, that would get my vote. But of the 4 tests you mentioned that use > >> clock_gettime(), it looks like transhuge-stress is the only one that d= oesn't > >> have a pass/fail result, so is probably the only candidate for moving. > >> > >> The others either use the times as a timeout and determines failure if= the > >> action didn't occur within the timeout (e.g. ksm_tests.c) or use it to= add some > >> supplemental performance information to an otherwise functionality-ori= ented test. > > > > Thank you very much, Ryan. I think you've found a better home for this > > tool . I will > > send v2, relocating it to tools/mm and adding a function to swap in > > either the whole > > mTHPs or a portion of mTHPs by "-a"(aligned swapin). > > > > So basically, we will have > > > > 1. Use MADV_PAGEPUT for rapid swap-out, putting the swap allocation cod= e under > > high exercise in a short time. > > > > 2. Use MADV_DONTNEED to simulate the behavior of libc and Java heap in = freeing > > memory, as well as for munmap, app exits, or OOM killer scenarios. This= ensures > > new mTHP is always generated, released or swapped out, similar to the b= ehavior > > on a PC or Android phone where many applications are frequently started= and > > terminated. > > MADV_DONTNEED 64KB memory, then memset() it, this just simulates the > large folio swap-in exactly, which hasn't been merged by upstream. I > don't think that it's a good idea to make such kind of trick. I disagree. This is how userspace heaps can manage memory deallocation. Additionally, in the event of an application exit, munmap, or OOM killer, t= he amount of freed memory can be much larger than 64KB. The primary purpose of using MADV_DONTNEED is to release anonymous memory and generate new mTHP so that the iteration can continue. Otherwise, the test program becomes entirely pointless, as we only have large folios at the beginning. That is exactly why Chris has failed to find his bugs by using other small programs. On the other hand, we definitely want large folios swap-in, otherwise, mTHP is just a toy to Android or similar system where more than 2/3 memory could be in swap. We do NOT want single-use mTHP. > > > 3. Swap in with or without the "-a" option to observe how fragments > > due to swap-in > > and the incoming swap-in of large folios will impact swap-out fallback. > > It's good to create fragmentation with swap-in. Which is more practical > and future-proof. And, I believe that we can reduce large folio > swap-out fallback rate without the large folio swap-in trick. > > > And many thanks to Chris for the suggestion on improving it within > > selftest, though I > > prefer to place it in tools/mm. > > -- > Best Regards, > Huang, Ying Thanks Barry