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 7BBEDC3DA59 for ; Mon, 15 Jul 2024 14:10:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D1D296B0085; Mon, 15 Jul 2024 10:10:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CCCC66B0088; Mon, 15 Jul 2024 10:10:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B9F816B0089; Mon, 15 Jul 2024 10:10:35 -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 9B4106B0085 for ; Mon, 15 Jul 2024 10:10:35 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id EFCD41C0240 for ; Mon, 15 Jul 2024 14:10:34 +0000 (UTC) X-FDA: 82342172388.24.9159F15 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf22.hostedemail.com (Postfix) with ESMTP id 34CCBC0024 for ; Mon, 15 Jul 2024 14:10:31 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; spf=pass (imf22.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721052613; a=rsa-sha256; cv=none; b=fTY/GgYbPiXqsO1+QNK+mHv0Zxn73+qPJnMaNf9oaSAVE5ezqrFIU/UCDnPq/FNmtHyy61 4f4kT4aZUAFkc24SO8U3KVTb/XjyerPZgn+dhZnrx7aat+Tz25gqqUXwpK7ZnhIosKk8gX GYNCctSfBUxicDcdRT4g5CoEyaNUrTU= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; spf=pass (imf22.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721052613; 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=kBD7rd8EP4SZU2hdYV0IYp9V/jtWMihh4aw5qPx69CI=; b=0DO4TaLqwrAkdrptNEcv0W8VajfotRRwZcdtkqYuhP3GfwkDQSRLfipXporFC1PI/8YQAy cmKwAW9Wyy0fWMaNMGP4qsvfp6htTPnIg9f4wA0ZRPb9eXLBRuZI6UpVUr9M2Wbx4PZVBI pD5zxYIE3CI/Rhfy/flT1cioS96r2DA= 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 819A2DA7; Mon, 15 Jul 2024 07:10:56 -0700 (PDT) Received: from [10.57.77.136] (unknown [10.57.77.136]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C76F43F766; Mon, 15 Jul 2024 07:10:29 -0700 (PDT) Message-ID: <96965a23-49ea-41f5-a4b0-9b5296dafe00@arm.com> Date: Mon, 15 Jul 2024 15:10:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/3] mm: swap: mTHP swap allocator base on swap cluster order Content-Language: en-GB To: Chris Li Cc: Andrew Morton , Kairui Song , Hugh Dickins , "Huang, Ying" , Kalesh Singh , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Barry Song References: <20240711-swap-allocator-v4-0-0295a4d4c7aa@kernel.org> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: a7ywd13qyhybxdcy35de9xfd9ktpas4m X-Rspamd-Queue-Id: 34CCBC0024 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1721052631-443938 X-HE-Meta: U2FsdGVkX19wpRNiT/RJN8IuuY3wY7QIUdY53hbVaYe5kgzqR6f7vaOzReVV7ARoWilVQQ93dddX9bua5wWPxAduQBBJ1bcsGwR++TZlf4a8izwfryUCked0OsNvQh4vOPjMFMruc3n/gC7r27noR1CRtABgkWwtp8CzLO66ORcqIJVS+APN44N5BKYG18Fl+LQ4fkG0mtX4LGE72b3FrWJDEhNCnf1SVWsnAWzy9U8g8tlfvmFNekRSfjnejjMg8WEz/eGdbPvphyABNO3jWxjD2G9Yvwp8A5uZL+1kWtD66Sfzeu3pANbAD4ortif17ViT2gKndhHt7c5oSnmTZUx5eFqBRUQI/eMTDNukbRk0Zr62d99GVTFE9XurbI9ZZBZyZtGvSSEvuSa4XOk5hfID1iEGEk8+m95zryspf928r4xftpwUJHbsdC14p2kiodDUxvYkOWVDdfhXJSfeWRRSWK6Bb4pKWPgNakRwFxpo2NSf4AEcbHLhnOc+nkbkEQ0J2tJSsM4ZCfIHwJWrJxflbcz2Dwk1ExuXhXH+t9fvFzNBsF1h3Rdgyfm4XxlUVIqsRbA12HEHBRDpBHOdGlXrMfRYSpFYM9eQ6/ZPa0CBKmP4EhmNGyRgiGz641FtCk7e5QK81+IaEUgv2cZ8vOtP7Qmw2qjr8Ogtx9qP0MF+mzwRaOsMh1dfp7G4UPMJo6Bstb760TpgHvd+bgKmKqw9Dj/AJJKIZOzf6tmn3oiFvTdcBZUsFV7jziw/EQj23oQXoXmeX1i7Fk8tuhLhgM3lJQOiC40EmZYV5qC2fOshoP1PUs8B4RMtac1ZboJXjBiaMo/XxWLJ/1xiHM811rc/LsFUi9V9p2UPbdnsDUlhS9kKnNQ2QlCOR+g63g2iT06zydXFTH9aZSKCkumYeuNC4bYaqdTakaFqYWjJqjesXw9R+8de9W8x+H8d5IEjvLqNyd3+IaFzgwEBo5N bqevm1yl fxh8MWZkmkFv9GxIq5TfgG9k4UrW35LLg/PUr4jt32nS2cvtvVLbd4uyCnOo6MJOOkyC7SjK1eSpKLy1+2mawz1hFKuok092aIM5aWzr2mjjrdIIY7yK9uaLic5HDeKc8Z364/+buaTBNYkUiWOVYo2l7iZiKxxFu9W/dtatRYCLk3ThvZ0pvyrzSv0TRvCd6b9j787zqWxQAENg5C5YmIb7Rb3Pi088cF6lC 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 11/07/2024 15:08, Chris Li wrote: > On Thu, Jul 11, 2024 at 3:02 AM Ryan Roberts wrote: >> >>> Kernel compile under tmpfs with cgroup memory.max = 2G. >>> 12 core 24 hyperthreading, 32 jobs. >>> >>> HDD swap 3 runs average, 20G swap file: >>> >>> Without: >>> user 4186.290 >>> system 421.743 >>> real 597.317 >>> >>> With: >>> user 4113.897 >>> system 413.123 >>> real 659.543 >> >> If I've understood this correctly, this test is taking~10% longer in wall time? > > Most likely due to the high variance in measurement and fewer > measuring samples 3 vs 10. Most of that wall time is waiting for IO. > It is likely just noise. OK, that certainly makes sense, as long as you're sure its noise. The other (unlikely) possibility is that somehow the HDD placement descisions are changing, which increases waiting due to increased seek times. > >> But your changes shouldn't affect HDD swap path? So what's the reason for this? > > The change did affect HDD swap path in the sense that it did not need > to check for si->cluster_info any more. A small gain there. > > The wall clock time is more than double the SSD or zram. Which means > most of the time the system is waiting for HDD IO to complete (wait is > 98%) , there will be much higher variance for sure. At this point the > wall clock we are measuring the wait mostly, not the actual work. The > system time is quicker, that is good. > > I now have a dedicated machine to run the HDD swap now. The HDD is > very very slow to swap. The point of the HDD test is being able to > complete the run without OOM. Because of the high latency in HDD, > there will be more memory pressure. It did catch some other bugs in my > internal version of the patch. > >> I'm hoping to review this properly next week. It would be great to get this in >> sooner rather than later IMHO. > > Thank you. This new code path is much easier to work with than the > previous SSD and HDD mixed allocation path. I am able to implement the > cluster reservation experiment in the new allocator much quicker. > > Chris