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 ECA2FC27C53 for ; Thu, 20 Jun 2024 01:55:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 637256B02EF; Wed, 19 Jun 2024 21:55:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BEE66B02F9; Wed, 19 Jun 2024 21:55:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 411AB6B02F7; Wed, 19 Jun 2024 21:55:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 1779F6B02E9 for ; Wed, 19 Jun 2024 21:55:52 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9BE271C3189 for ; Thu, 20 Jun 2024 01:55:51 +0000 (UTC) X-FDA: 82249600902.08.E7602A0 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by imf17.hostedemail.com (Postfix) with ESMTP id 2E05E4000B for ; Thu, 20 Jun 2024 01:55:48 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=WPMSPr+o; spf=pass (imf17.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.9 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718848545; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=x208/m26LaVjZ1UUBiYkdZyKyhsg17oTRjYt+yC/s1Y=; b=yToUGzMvs7Th2xAFNZ5vjOljmVK6cCw/E16dZDFDiHv4Rt/dhpAyTcLE0rPdPuWs0hrFE7 C0bZSYBmy7tstuSo+i6BW8TDHysTvdIw2ECzg5QPncyILZBCYVUzGEJkHe3ZAAD1g7QnyH jg3OpnZ4xO11fFSCHuDAFpIZ20VxhoQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=WPMSPr+o; spf=pass (imf17.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.9 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718848545; a=rsa-sha256; cv=none; b=Ab1Afw+YULfjIcczqiiTzwNsdCbw+Aqo7LCUvJYM5BrylVSmgF/tPz+7etXaYbPSp6Gwfa /TpWRpv67035M1/M/NO/w6u7SABxhOXnOibSR1FVW5B+wq1C9UbzyFxN74CkHO2Zz8eDAi jlkyFvEN8RXZv0jO4vm5Ti7gaE8w2Dg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1718848549; x=1750384549; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=oYiCbiHBTA6hmiZiPSlVupDRi4CFIhK9ABCT+BZpfDE=; b=WPMSPr+ouY0dKzEvA1qSTXoUIIUzjTnl8bYX4wKNgyi9Sa67lUuovxeF FPlOj1s5v27M9o/2wXYKPswjaGgb+izk9GJFRFgeYDgKqkLqxWy160Ma6 LMALxp8EDf6Glvbgg+/fRzskuDo5ZHhSi4vOQY+DNlX4WAD3FegzR4xxy 65qDiFWOXfL/ta1K2Nf+lyA3/GyoLQpRaKivD8sybZ7MlFnGfMU19Up5Y EZo9FOMpR0uGmpzk6bErsJw+3Wt0EKylwETCXdFlaaLH/okJdjnkw7Jop M845p8051DG/oVnx3cYSOiynxs9yhM5InxHYHepMOPmgX+Oy9JhUKMFmh A==; X-CSE-ConnectionGUID: LaS2Vhm8QXaO04hykCvOxg== X-CSE-MsgGUID: LdFw7VvUTR21RjPENyBmIw== X-IronPort-AV: E=McAfee;i="6700,10204,11108"; a="38318188" X-IronPort-AV: E=Sophos;i="6.08,251,1712646000"; d="scan'208";a="38318188" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jun 2024 18:55:47 -0700 X-CSE-ConnectionGUID: bvHPT9LURfCgiupFdU7bWg== X-CSE-MsgGUID: J9K3wdFHT++zEai5EBrbtg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,251,1712646000"; d="scan'208";a="46454253" Received: from unknown (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jun 2024 18:55:44 -0700 From: "Huang, Ying" To: Barry Song <21cnbao@gmail.com> 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 Subject: Re: [PATCH] selftests/mm: Introduce a test program to assess swap entry allocation for thp_swapout In-Reply-To: <20240620002648.75204-1-21cnbao@gmail.com> (Barry Song's message of "Thu, 20 Jun 2024 12:26:48 +1200") References: <20240620002648.75204-1-21cnbao@gmail.com> Date: Thu, 20 Jun 2024 09:53:53 +0800 Message-ID: <87zfrg2xce.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 2E05E4000B X-Stat-Signature: f3jzpz7tdsrk7hq47ye19tem3au8uric X-HE-Tag: 1718848548-274785 X-HE-Meta: U2FsdGVkX1+Bn9Nl8LMPc3jurV3misEBLV/9Nk68ZjIgidwFDb/ahUhUXspNfOLacQ3IqlirJEWA7bxC7FyrH2IWSmvQdRoePvjbM+1EUkPRSqAgUsqkn6562qTm+DOYsfDM4RkUYiri8/N+uC8trHaLcdq3aDeq1vBPC+AgQsecK9fLWWtvbLswm4IHyiZBfJPN650S7MnnZH96JOWtQK7v4xblxe/LQ+p1R8aP/X8WVqPMCTMhF6QXHeSORspFUm8k9lcQbqUnUjhoU3T+kbaRWRwAiJGhuD3ehwTPDp8lllx0FjlgpdzoxXXnTQY2XEDdnrpxKwZqeqlaJfipE5qlG+Oll+WINwzdiK2fJgMJN28BroNEir42y2lRJHHILMamTCZ24vn+qKXFlDzuVYGQbhDFdTsgkcJh0umbEsQaptbtMNDXUPBq/JdejscNT7PJxgM9eiycrQ76r3StIflmwXn9hUUY61vNxR0HmmjYzSvTRIWxvxTgbJXoPWo0XjMBYNEnVb40XLlZSvasnaQ6pYr9aLE49HQ5wOpKUpP6DaL94BcItGeu6MsGVCH/OE3wGgxhST+cb7D2+mLO9q1SDZxa8hVGc43PPHuG4x3jU9QTerMSvzzFYK4pkqk2yjnT4U+modqFhvi4IqQfLtYK6CNSRrbcgJUsGfgSwU2RkfSektsCrtTWAKDPI+5kZsQf4W8BN0Tq8OzH9w6DegX9kO0e5DQHbqVVxKpJY7qfyJzBNwxdfk87XFZua6TKGwqtgki+G7aYgWBSTMmKLJu8hJqw/sVFa6VYucOg8mV1xRjgYsXmwQxkJIgDJu4RrahZ6wvuRt9n38KEDiI1ODuFdRLKBR81pZg2RBR2OSCQ8I9rOsEZrrO/ookfCN1WD1X7QNr7OqPMHLrrdQvauM6TeR+ITWpsY8eZoydLcTsigouP3chtmL4w/CrYVeYRjNOkVCkzB91gVe2LyuQ pka3e/dZ SY3H+2V/WCpA2tjsfcCj0ZIFYJti/inD4a2kl0yQjQKU3DT3nER9o9d+2KVSxGChZXoi5FaTdKNwTwXP2yUqkE1zS2G+Prw/LzJICy7MwuqsAvbXcSiHhduKuyWTgbUZLvQp8lz7gcwzUIi777G5VoLPpfHBcLFhlQqKvV8A9rD+v7ECWyYdQ8jQtCaky2sv365GxCeViDQjCtOUFlU14GnBn8+RtmCdhEOjiREX4nEXmSZJsZiJ8/MMiQUBcWWQpQutyDPDwRWgeg02KP5txdlG3zDu/LJjoxc/gse+pEv9R12k= 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: Barry Song <21cnbao@gmail.com> writes: > 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. IIUC, this is a performance test program instead of functionality test program. Does it match the purpose of the kernel selftest? > 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_allocator_test.c > > diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/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 += mseal_test > TEST_GEN_FILES += seal_elf > TEST_GEN_FILES += on-fault-limit > TEST_GEN_FILES += pagemap_ioctl > +TEST_GEN_FILES += thp_swap_allocator_test > TEST_GEN_FILES += thuge-gen > TEST_GEN_FILES += transhuge-stress > TEST_GEN_FILES += 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 THP swpout > + * can correctly get swap slots to swap out as a whole instead of > + * being split. It randomly releases swap entries through madvise > + * DONTNEED and do swapout on two memory areas: a memory area for > + * 64KB THP and the other area for small folios. The second 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/hugepages-2048kB/enabled > + * echo always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled > + * mkswap /dev/zram0 > + * swapon /dev/zram0 > + * The expected result should be 0% anon swpout fallback ratio 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/stats/swpout" > +#define SWPOUT_FALLBACK_PATH \ > + "/sys/kernel/mm/transparent_hugepage/hugepages-64kB/stats/swpout_fallback" > + > +static void *aligned_alloc_mem(size_t size, size_t alignment) > +{ > + void *mem = NULL; > + > + if (posix_memalign(&mem, alignment, size) != 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 = total_dontneed_size / align_size; > + size_t i; > + size_t offset; > + void *addr; > + > + for (i = 0; i < num_pages; ++i) { > + offset = (rand() % (mem_size / align_size)) * align_size; > + addr = (char *)mem + offset; > + if (madvise(addr, align_size, MADV_DONTNEED) != 0) > + perror("madvise dontneed"); IIUC, this simulates align_size (generally 64KB) swap-in. That is, it simulate the effect of large size swap-in when it's not available in kernel. If we have large size swap-in in kernel in the future, this becomes unnecessary. Additionally, we have not reached the consensus that we should 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 reflect current situation too. > + > + memset(addr, 0x11, align_size); > + } > +} > + [snip] -- Best Regards, Huang, Ying