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 9753AEB64DB for ; Wed, 14 Jun 2023 17:27:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F037B8E0003; Wed, 14 Jun 2023 13:27:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB3A78E0001; Wed, 14 Jun 2023 13:27:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA2058E0003; Wed, 14 Jun 2023 13:27:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id CA6668E0001 for ; Wed, 14 Jun 2023 13:27:06 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 76E84C073A for ; Wed, 14 Jun 2023 17:27:06 +0000 (UTC) X-FDA: 80902034052.24.AC3E212 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id C83A540004 for ; Wed, 14 Jun 2023 17:27:03 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=pMAWwNPV; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686763623; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mXsoJTj9V51Mwa5uVI5Ta2wlAZcIfKmqGuBEE3dCSxY=; b=Pw3gpRfIaFjyxSxT2THpaGC3Dj12vPRwZeRS2j/i2XZirOiFRDRDYXZF4dHRVdHAmRLDUj h0kAsX/jy7qXQ1wXidByqnfmxu1U3kzplbup9Zew4Zd0dkbg8XWYdP18bWPADKLPeymkTV Q+Qb4MCHOkaV1FGn0EpUXBvj3ZGLyys= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=pMAWwNPV; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686763623; a=rsa-sha256; cv=none; b=yJslTpETff/2joAv7cN+W4N2PCCrkuMxqUwqIFNVXytl8zDuAMUK1gZIVhaUS6PBiBJ+2n yqmFDoDrTLTS4izW/EeTbHRYqvlno9VoqrfI1/KbgLifvf1EcS2ql0HLJTzO7ADXw5TqyA TZvV2Cc6U2Eoo+hNNE7DJYuVWuITWAQ= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9AADA6451A; Wed, 14 Jun 2023 17:27:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85914C433C9; Wed, 14 Jun 2023 17:27:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686763622; bh=nOmqxI9b0TrFL/JHYbhyIO1ZCsdC/twp0abB7a7rTBQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pMAWwNPV4mXfAWAAqgNMb0OaqOwo+bWwwWfB0RpASEJtKRSGel2zdH3s7H78hUst8 lhvrDXq2i1WA4R8Dc5QfB1a6hCjaMeX6yvcMalSH3ldE9P0r0tau68O2Q8uCZFSzeU 3y2PkRPIJPvDWMKvzGVUZ3ip8nAL0c9dglYrnZkYHy3zr41AzzF4JCPMnSAWEHGlH0 WsW3F2cvdMwuBV0XSvjEPhzK7f1dRStpopCRUoCqs/iGGzxF4r6Lvm/y/bUC7CFiz6 6u6B/7GKBkkqz3y9P+7qBDmLCXz76IjlzDKpyZHaNU9gbu/le20ekLl0jMvHvw2TQx ZUONulM1fhk8Q== From: SeongJae Park To: Piyush Sachdeva Cc: sjpark@amazon.de, damon@lists.linux.dev, linux-mm@kvack.org, aneesh.kumar@linux.ibm.com Subject: Re: DAMON testing and benchmarking Date: Wed, 14 Jun 2023 17:27:00 +0000 Message-Id: <20230614172700.82480-1-sj@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: C83A540004 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ydma3kwtjttdogxdbb3a8tbyt74yphot X-HE-Tag: 1686763623-663489 X-HE-Meta: U2FsdGVkX19+p17gIPfNfYmOSC5VkuyeuZanz+x2Lo/GpkdrBRipvU8DbK4YBR89k1ca/4CbE7lwkIAfQBmIKYVkQ7DLbjEEpg3cBe4ucrpM1jJzN0ntwrJs3+Xrq50cnGkZwsrPrHNp0rXEPUDIFMcZwHm6Csf1Dn1BaxLnaIxE2bne24/ZDXle3F0dzdUMnPEbNuq6ZBqycBFlQ6Fd4nYvLVcoc0Q19DvRfEqmXEYTKie2O4yF2Fzn5t1SXeKYQxG45FFkWA7E4SsB0vQmDFKQuOJ0QsmqxeyoGAf3t/u+1zbV3WXq97zVps+Gd2CYxqOZNP6gzXCfYPAsSnsDllNhwDTkNXIkodAGf/KQiceQFsg1sQcAZ8wft3b0YhJ/vXEP3oq5uihWz3UtiXMr/22Xaf4+7u2jMWUG00AmRsnEzSRAVQ1Ux/62lF29Cxw3QVoKUf0V9XXWajlvoBO5QU77MhSnPwz+KvslwlKUTR4mHRwza3QO9CSjM8iNCzWd0sVHdMfLkE3ZYjYlFsbRhbdZzcWvWOQp+Z9ObugMBk5mHSnq2LzkPe9LBPFndckIVGyJB7z8VvLpS4R/S0LgABH3HN/TrR3tVOZyUH5Hcoi/guFBwgJfVqmfijUw7/BptmAP2CqoYsSGFXmrkax+88bCJSYgiw20Qd7NK2BUlEPuua9qBcNdqyLVA9dc1Kl1ggkwgk3xI+JyMiY1rmxxsoeCj1lBd6YY8sHvAzPNBpMfk/WAc20AlXMKjQ86z/0Y+hxbE2QGtpREkcL6z1NrCUuYGqXL1OkuJ4IIxFfvPl+Kw0w+5lno4N7HYtPL0PFSrW0LqQO/QFa746bkw0Z48I+f4gKkrAT64A2LnwtOTj0xi8OHFyrmBUbq3q4TmMj6eRgu/zcWFWUSDMV5BLl6djKZ375QPB+qMwvukTPIh9/rRJGfOII3PxS5U4vB2tautY5ubtp5sqiNA/RgdzW +855rxFc hx/C8J6qxdLXyIEABIZhXm9PeaJ8iGJZLE5crByP87H7zYlxe30l788b5YdtsvM1FqCVgTfezg+FaAskJVZfHSJJY8njMXnWKc69ZLIeTqY4ZyewQzUvNMX0qlpsJQIV9zK8Kqk0l+hExvkFMx7jbO+qct5UkOmzPYR/i1pSVyzqMwoyk7kg6WqI02V73tO0LEjX31spx3VM4J6WsNaLNPLXvOsL+Xhy6tKyr7o4SxZDseKCFCvLGynEl9pRaFqZqenPCU1vxdNAGIfCxrjgHQLoOtYZ9z4dnJfSas+xDCZWY1ei966O67ulkQ0mL37fiBa9uxGNGecr7vyxy3oA5YikkUnQ+CAIGg4WsuTulPqnSxnXEfxEiHIbFnbdXuEYcXrx4LNzpjPRF8ysuPSVas08jgQ0jJ9L7cKwBaGjL5QVpb6BfbuBS4OWkAi6N3CcI44x7RhGJft6xnaXdA4eaFIBhpyC22iQku57XRzwg5uOJPieUbUnz5ff/sQ/6SLZw3S3kYi59KWZXM33yE6hbfPV0FkqABEJI8X2q4dLPuhCF4Ek= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001020, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Piyush, On Tue, 13 Jun 2023 12:18:48 +0530 Piyush Sachdeva wrote: > Dear Mr. SeongJae Park, > I hope this email finds you well. It did, thank you for this email :) > > For the last few months, I have been looking at DAMON from an end-users > perspective and a developer's PoV. Most recently, I was focusing on > `lru_sort.c` module that uses the `lru_prio` and `lru_deprio` operations > which result in a more precise reclaim. In my understanding, enabling > the "lru_sort.c" module would make intelligent decisions based on the > access frequency of the pages and end up preventing hot page > swaps. Hence, when integrated with an LRU algorithm, it should improve > it. > > If you could share any test/benchmark that you might have run to verify > the above assumption? Yes, of course. I will share those soon. > I did find the result numbers you posted (link below), but that doesn't > mention the "plrus-*" scheme numbers. It also doesn't have numbers for > running the `pageout` operation on the entire physical address space (paddr) > i.e. the `pprcl` scheme. So, if you can link those too, it would be amazing. We run an automated test[1] every day, against the latest damon/next tree. And the page you linked is the output of the test. The latet version contains the results from `pprcl`[2] and `plrus`[3], but I was too lazy at updating the document, sorry. I will try to clean up the mess as soon as possible. > > Can you also share any real-world (memory-management specific) workload > results that you would have used with DAMON in your experiments? Like > either MongoDB or memcached over Parsec3.0 (including splash2x) - which, > in my understanding, is less memory intensive and more architecture > inclined. On my personal testing setup, I'm using only parsec3 and splash2x at the moment. We heard some production DB system is using DAMON_RECLAIM and achieved about 20% memory footprint reduction, though. > > I also had a question regarding schemes - A scheme is highly tweakable, > and it's what the efficiency of DAMON rests upon. The more precise the > scheme, the more efficient DAMON will be. Hence, I'd be thankful if you > can help me derive a config that would provide the best results. Very good point. Unfortunately, repeats of experience and adjustment is the only way as of now, like other tuning practices. Nevertheless, DAMOS supports some safeguards such as quotas[4], watermarks[5], and filters[6]. Because quotas feature provides prioritization, setting the access pattern a little wide, and more focusing on tuning of the quotas might be a good practice. I'm trying to add some more easy-to-use intuitive tuning knobs, including feedback-based quota auto-tuning, which I shared the rough idea at LSFMM[7]. > Hope to hear from you soon. Thank you again for this great questions. Please feel free to ask any question or helps :) [1] https://github.com/awslabs/damon-tests/blob/next/perf/full_run.sh [2] https://github.com/awslabs/damon-tests/blob/next/perf/schemes/pdarc_v4_2_2.json [3] https://github.com/awslabs/damon-tests/blob/next/perf/schemes/plrus-2.json [4] https://www.kernel.org/doc/html/next/mm/damon/design.html#quotas [5] https://www.kernel.org/doc/html/next/mm/damon/design.html#watermarks [6] https://www.kernel.org/doc/html/next/mm/damon/design.html#filters [7] https://lwn.net/Articles/931769/ Thanks, SJ > > Test results: https://damonitor.github.io/test/result/perf/latest/html/ > > -- > Regards, > Piyush Sachdeva >