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 5B81EC27C4F for ; Fri, 21 Jun 2024 07:58:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D4C048D0144; Fri, 21 Jun 2024 03:58:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CFC378D0138; Fri, 21 Jun 2024 03:58:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B9E588D0144; Fri, 21 Jun 2024 03:58:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 9418C8D0138 for ; Fri, 21 Jun 2024 03:58:55 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2F16CA0B59 for ; Fri, 21 Jun 2024 07:58:55 +0000 (UTC) X-FDA: 82254144630.15.D439EFB Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf20.hostedemail.com (Postfix) with ESMTP id 254AA1C0012 for ; Fri, 21 Jun 2024 07:58:52 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf20.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718956722; 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; bh=aL2xo00O+UO0xcV/9Yx0M/yihjlDTjDoW/ZncRZ4hgA=; b=KisH24NkJr0j3gq7DhNiXlIF5wrSZ4pK4W9o6xBWNCnpMFkNGVAJ3kIjBMnKAnaYU+I0kw L2F7+oRiONMVpWpZsRzfaTz+EldB+Bxsb2/Z7gSKqGbIkI0SSHhjipK0EkEtN/1oV4A7VN skziCi2nkg+n+0W5vp9Mg9hwgf4Uf+k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718956722; a=rsa-sha256; cv=none; b=DBUFXyWXDNykTX6QSjRGRA+GRvZuocVuMz5FqHOTur5uALMDfkFjJFvy8JYhyCQVtPg7Vt YmD3GR41Sm0h7ftgnmnBL4CiTBc7nkBRAWMZ/3+k12MqyeasDf5e7yh7hzx/UW66Aj48gI QNAFirdYricSwibtoUGywN+JMRGzqXo= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf20.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2BAEA339; Fri, 21 Jun 2024 00:59:17 -0700 (PDT) Received: from [10.57.74.104] (unknown [10.57.74.104]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 950893F64C; Fri, 21 Jun 2024 00:58:50 -0700 (PDT) Message-ID: <1bbeb797-e07b-4c75-819f-7ce5f785037e@arm.com> Date: Fri, 21 Jun 2024 08:58:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] selftests/mm: Introduce a test program to assess swap entry allocation for thp_swapout Content-Language: en-GB To: Barry Song <21cnbao@gmail.com> Cc: 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, ying.huang@intel.com, linux-kselftest@vger.kernel.org, Barry Song References: <20240620002648.75204-1-21cnbao@gmail.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 254AA1C0012 X-Stat-Signature: pamupdys3ajwunqn3qtaq3ydkgconcrp X-Rspam-User: X-HE-Tag: 1718956732-20136 X-HE-Meta: U2FsdGVkX18q34IkkVm5MchCpwgeIcq8g/lkER4FtMw6s/xni+sDuzPVrn6ncm0XREHnP54e6ZELeKKFQn+aVNDnOYGgAl1DE+39SyzfT5NGgDAUtdCCw3VoUYiesEmrIYziX4eaycV8PZwc/gzrL/pbZTkJ9+s1Cd9HAahC8nVqeCwIa4hIt1C+k0MGxTtEIWss3ZOBaauFruQPtHZ+wRupMNRr46qRdgR66raBqsw5zBC503B3KQiOxQ389Nq36+xJHWcYw//aJfFN633iIY0QztY9TJjW7v0q28exX8FCQD8UFVqxvanLLkP+Yw3/o+pT0bhriPxsucgaJIikyxDtZS5AJ456F2lwZT7DibyEMrU5HtJh9slqWzSW9um/IKkLVHxB6QVRgKtQKIjyzaCEs6KEfnM4dXu6ImBndOmJj2yiyZtXn3X9ysQzaQTuLkAKschRjet3lNHokdn1iMnN81BOUI9VP1plEC+KYQulLHjTpwEb8ku5uHVITW1P04J5OSdX1z9N9FApb2l4qY/VX5+/EYAPRmgeXYhYVvxTpLBxkoMQCIZj1U8kEdsdz/o5im3W/iyF/VHhZNwB/NeMvI/XYjmcXPzHS9pz03iIqDtdO6ut9TSKvRw/K+Ijc1fL9EYkm8LQbHm0jxYpU1CRUs5nbJXMYk60o2zJZMdSHG2L/LgUnDN0/u28tUL+qw6TBKV+aXezC3SyzpPQdrgtowYGF+WqZhHzSVWZ76Liaq5aBrWu4IFlRPfYYHbCDN7GZumnsd4keth6yt1q3oB6G5kk6E5DC5Ce5a8Lz14ZDDf0GYNA7TIBBlZCnvvoOZa1ZiRfa+o212ypL00npjX57WJlhEFhm41GeFj/gWHuzo5Al6hp3wA0yK8rhwMdLomNwm9FOT/tQaECEyOLLTEkaDT3RbOhu9OPKkTHAkkjZSHNd2ruId0kfd2bhmwte1xyfEAZU5Fpjxrf/Cg V6FX9+vF ovBtAWMhR1ye5/hxwkIy/cug1HXCn7hdQ/BG3hgKZ720IfocYrcPJOkwQHTulpCO8+3h0loF/WTv1Apjn5hsd8i/rcgae7hd9a9u1xiKczm0w7jh8mebbMF+k+9DFYA+oDotePXaPSJfXpb5tx2dBJnpcsf941nLiIpGKT1+h7TGzVnlKHOc/QC/SfgLYHxRHEjITGZJm8j3dODqZH+Duanql6XJG92wcEoFWhK89zTTojkayZNQKOPr26WrmK4ndj1iK90JRZ0RanZ+bjrJd9Ywq+Mpj0PiCmfAl6AOLlqmjhK4BzDzGCwxYlIq7jXWZbqgHEzFpIhPmyhV9QomfbzKbRQ== 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 21/06/2024 08:47, Barry Song wrote: > On Fri, Jun 21, 2024 at 7:25 PM 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. While >>>>> a real or intricate workload might be more suitable for assessing 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. Although it >>>>> presently only accommodates 64KB and 4KB, I'm optimistic that we can >>>>> expand its capabilities to support multiple sizes and simulate more >>>>> 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 swap-out path. >>>> I've certainly found it useful and think it would be a valuable addition to the >>>> tree. >>>> >>>> That said, I'm not convinced it is a selftest; IMO a selftest should 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 doesn'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-oriented 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 code 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 behavior > on a PC or Android phone where many applications are frequently started and > terminated. > > 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. > > And many thanks to Chris for the suggestion on improving it within > selftest, though I > prefer to place it in tools/mm. All sounds good to me! If, (for future) you also wanted to test the vmscan swap-out path, the way I've been doing that is to run the workload in a memory-constrained cgroup. That means you don't need to exhaust all your phsical ram so speeds things up a lot. > > Thanks > Barry