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 2EF42E81E17 for ; Fri, 6 Oct 2023 16:28:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B80DA8D00D0; Fri, 6 Oct 2023 12:28:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B30BE8D00C9; Fri, 6 Oct 2023 12:28:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D2B98D00D0; Fri, 6 Oct 2023 12:28:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8C5858D00C9 for ; Fri, 6 Oct 2023 12:28:16 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 61B4B1CA5FF for ; Fri, 6 Oct 2023 16:28:16 +0000 (UTC) X-FDA: 81315568992.23.2A827D8 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by imf29.hostedemail.com (Postfix) with ESMTP id 32ACA12001F for ; Fri, 6 Oct 2023 16:28:14 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=devkernel.io header.s=fm3 header.b=cLi8DYff; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=Sn4wefnF; spf=pass (imf29.hostedemail.com: domain of shr@devkernel.io designates 66.111.4.25 as permitted sender) smtp.mailfrom=shr@devkernel.io; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696609694; 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=2dW/PhGhZL1Lh2ZgVhKfLyMXlLp6UoQWQqOjD8RsV10=; b=V5+QmhJtqezV746e3pTYqOVwEHUGuV3DW1ORttQLOy9yLLa5AFBG1FhrVGLEeMZiobPzrC 3czT7pGW/LZC1i9z0KOTwBsXYN+QkTsAV+Qy+csdcojYxd1Pg0u5vR1OHo3HAbvt2sjggV MZJXLlcb05abrn+D7pi7E/+qAnCiXnc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696609694; a=rsa-sha256; cv=none; b=1um97hEOi+z/m9pUu9+Hj2L8tVi9E0TRk/QYaOBUeZ06nBKfQ6I1R4CrQ/U5K/6zNYstRE ngkWztzXrNbqNYFMeqRWH9k04zEEEwrI8+Dao2SiOrTlfK/jafYDK5/6HY2WcCNnzl9u6o 1g7YO4ZWUiWJOVQffMDwbkgxXoeA9Io= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=devkernel.io header.s=fm3 header.b=cLi8DYff; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=Sn4wefnF; spf=pass (imf29.hostedemail.com: domain of shr@devkernel.io designates 66.111.4.25 as permitted sender) smtp.mailfrom=shr@devkernel.io; dmarc=none Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6EB3A5C0213; Fri, 6 Oct 2023 12:28:13 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 06 Oct 2023 12:28:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=devkernel.io; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1696609693; x=1696696093; bh=2d W/PhGhZL1Lh2ZgVhKfLyMXlLp6UoQWQqOjD8RsV10=; b=cLi8DYffjeojMfh1Dv q7uzxOznqANC6PyQjtD2xy0XKYoUTAAmVbCbHDViPAx00/jnYHwGguxdjF5+ri64 INeocidXsISovnWWUeNxEVIKxSHG3IvOkfhMMU9gIBecbJPsUhCOWT8AMNRmqmtG f0HoviWT5o5QH18hV7of1rvChTp7FaN9tFmlfKmjVcLO4eYYtXQ3u0Txzt5fnhKJ 4vCr4Z/mSL7+7ucHrW3FbO03Gafjdb0STCPTwGBLTIVt6ytxDD15Vl5q8i/ng1h7 33DaOGTAV6EPnZtF40uRUN289PcprjcDMmhRiWRm7c/wpfah5DbCjxzy7ksVrtqw O58Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1696609693; x=1696696093; bh=2dW/PhGhZL1Lh 2ZgVhKfLyMXlLp6UoQWQqOjD8RsV10=; b=Sn4wefnFYw1VNTShs/wobCkjxEoCC gbzSmfmWPLa6z6GWTy8rGxSdUGWv7WUT1+kct7lnHFZNCWlZgBPgzn5gFDbnJOB/ g9U+4L1iU2Dp01shyr0NtKkufhC27QI+XstLDR+fgm0allg8PUCWV0zDSjd6aLVi 75dgJFiCuMsUGuhawuxMaNAL8c132JPPg9oHQ3KaGL9tVu1tNXbLY0gL4zZ7zTUm Go++o/o6yGUDz9C835qjzLAGxz8vQdAuG9OcA4KNKVt+A+M3LWaxcWNu6VCepsTx U5BDFruSBPl5TmzPl3+wMjAHOQBSbADnXQnSu+0PF2ipbzbs1R+CzWzHQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrgeeigdellecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpehffgfhvfevufffjgfkgggtsehttdertddtredtnecuhfhrohhmpefuthgvfhgr nhcutfhovghstghhuceoshhhrhesuggvvhhkvghrnhgvlhdrihhoqeenucggtffrrghtth gvrhhnpeevlefggffhheduiedtheejveehtdfhtedvhfeludetvdegieekgeeggfdugeeu tdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehshh hrseguvghvkhgvrhhnvghlrdhioh X-ME-Proxy: Feedback-ID: i84614614:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 6 Oct 2023 12:28:10 -0400 (EDT) References: <20231004190249.829015-1-shr@devkernel.io> <4509a3b4-16a6-f63e-1dd5-e20c7eadf87d@redhat.com> User-agent: mu4e 1.10.3; emacs 29.1 From: Stefan Roesch To: David Hildenbrand Cc: kernel-team@fb.com, akpm@linux-foundation.org, hannes@cmpxchg.org, riel@surriel.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v1 0/4] mm/ksm: Add ksm advisor Date: Fri, 06 Oct 2023 09:17:32 -0700 In-reply-to: <4509a3b4-16a6-f63e-1dd5-e20c7eadf87d@redhat.com> Message-ID: <87fs2nhg14.fsf@devkernel.io> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: a1zb9sd4zcukrjmt7ebygsw153eq5ch6 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 32ACA12001F X-Rspam-User: X-HE-Tag: 1696609694-2262 X-HE-Meta: U2FsdGVkX1+oVLrG0pE0WGU7PEzSIkkVihcMOwjZ+H0fVqVwmmm9A/F3mZASop04LTzj7h3KSnhxB51VpCinu2cqHWoh5Lc0y5hB28gBv55Ga4FTxhD6krp5V1FGqODKlZt3vfsO3YQUJ38eo1QNd3ov1LF4z/IDJKb34xQsp/Rq7D0PIt+Bi6BjaCxE9+7bakZrU9y/svTRt3eC1nVz9mY+3Mm+BjGfPnItf9reo9ypJ/oLlq4Rw273b8S3n0FBapobVlQp4081rzX6KdikZalUltWniSv+SrspXE3DAOXRv1gnz44K/jAB5vkIkvGIqUx4LvEWVrgxNsdZ4k9VYQuUszA2UFot6z7C6E5ejbbX43CiFXiZM+VqXxES3pTY0MIy/5XXnfJ5mzfrXIgRDFb3G7v/DtCN2RL29dxPV9lAL35SGfbvu6ehockc6gq8yeaXHpaBUpXOm3lF6UyhoQYhnngQURAFQNvV3kyoK1MoCiWiNWEpzEx1mRsrYJAINWqGJslRk1cxelmBko7+X8dLMNYzveOM0naK1eWj2/h4bd15MKxscfujo9WQeYWD3exeZtDNcJvumX9IStkVRgRKIoaM5rp4Twk2RyCbmsMH6xAlN/NunYA7JOkw1Zl5pYvI/a5nvbJK2WF1poD+ekwtO1/dRD5CkxR3eMImajmvb2ve7d1Js5gScvPkQh9gETaR1AhyRB47tirLw+irVVg+B2lufVmbTiMFL817u3dPYH1/tkj7nfW0TxW5h8vbUnHvo8np4coczsEKyksZ0w1A8+8OaFbXVl2kCqJsH+7N6zNzFXhQeKROaLNvMBOq/4cEkejxww0cnrEQtQh6XdJIRIA9zuRGRxfz57DU5GNQ0fMOY9EQduSd4hUwNjNaZPGr1eKHyQCJXbm3uV7OgQqIXRS2hp14Wr0KtjLgTWgtZYuWDdbHOAkZ9kePwyG24y8sv5eZOItFMhr+Cgs q3hv9gFW oiokoDoW1P0TnqwJZCt1YyyUW50BmoyczQ5kStKJ6DupYzMQsNT1thll47cWDkVhGKVVLpveYKWdn+ujmHO/cTjgFhrn+2sW+aKzvTNjVKbszl5vi71yCNVIWuDLRK9pRe/shMTzXxOdpUJGsod69vjZhW+1bIMBauIvPurMcCM2BFx8zdh2uFd6b/A== 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: David Hildenbrand writes: > On 04.10.23 21:02, Stefan Roesch wrote: >> What is the KSM advisor? >> ========================= >> The ksm advisor automatically manages the pages_to_scan setting to >> achieve a target scan time. The target scan time defines how many seconds >> it should take to scan all the candidate KSM pages. In other words the >> pages_to_scan rate is changed by the advisor to achieve the target scan >> time. >> Why do we need a KSM advisor? >> ============================== >> The number of candidate pages for KSM is dynamic. It can often be observed >> that during the startup of an application more candidate pages need to be >> processed. Without an advisor the pages_to_scan parameter needs to be >> sized for the maximum number of candidate pages. With the scan time >> advisor the pages_to_scan parameter based can be changed based on demand. >> Algorithm >> ========== >> The algorithm calculates the change value based on the target scan time >> and the previous scan time. To avoid pertubations an exponentially >> weighted moving average is applied. >> The algorithm has a max and min >> value to: >> - guarantee responsiveness to changes >> - to avoid to spend too much CPU >> Parameters to influence the KSM scan advisor >> ============================================= >> The respective parameters are: >> - ksm_advisor_mode >> 0: None (default), 1: scan time advisor >> - ksm_advisor_target_scan_time >> how many seconds a scan should of all candidate pages take >> - ksm_advisor_min_pages >> minimum value for pages_to_scan per batch >> - ksm_advisor_max_pages >> maximum value for pages_to_scan per batch >> The parameters are exposed as knobs in /sys/kernel/mm/ksm. >> By default the scan time advisor is disabled. > > What would be the main reason to not have this enabled as default? > There might be already exisiting users which directly set pages_to_scan and tuned the KSM settings accordingly, as the default setting of 100 for pages_to_scan is too low for typical workloads. > IIUC, it is kind-of an auto-tuning of pages_to_scan. Would "auto-tuning" > describe it better than "advisor" ? > > [...] > I'm fine with auto-tune. I was also thinking about that name, but I chose advisor, its a bit less strong and it needs input from the user. >> How is defining a target scan time better? >> =========================================== >> For an administrator it is more logical to set a target scan time.. The >> administrator can determine how many pages are scanned on each scan. >> Therefore setting a target scan time makes more sense. >> In addition the administrator might have a good idea about the >> memory sizing of its respective workloads. > > Is there any way you could imagine where we could have this just do something > reasonable without any user input? IOW, true auto-tuning? > True auto-tuning might be difficult as users might want to be able to choose how aggressive KSM is. Some might want it to be as aggressive as possible to get the maximum de-duplication rate. Others might want a more balanced approach that takes CPU-consumption into consideration. I guess it depends if you are memory-bound, cpu-bound or both. > I read above: >> - guarantee responsiveness to changes >> - to avoid to spend too much CPU > > whereby both things are accountable/measurable to use that as the input for > auto-tuning? > I'm not sure a true auto-tuning can be achieved. I think we need some input from the user - How much resources to consume - How fast memory changes or how stable memory is (this we might be able to detect) > > > I just had a family NMI, so my todo list is quite lengthy. Hoping I cna take a > closer look next week.