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 73987C25B7A for ; Wed, 22 May 2024 01:00:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 10F3D6B0096; Tue, 21 May 2024 21:00:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0BF896B0098; Tue, 21 May 2024 21:00:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF0486B0099; Tue, 21 May 2024 21:00:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CF9F16B0096 for ; Tue, 21 May 2024 21:00:41 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id AD2161C1121 for ; Wed, 22 May 2024 01:00:40 +0000 (UTC) X-FDA: 82144226640.08.6BDE1E3 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf30.hostedemail.com (Postfix) with ESMTP id 2B96B8000E for ; Wed, 22 May 2024 01:00:38 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ThGATGNl; spf=pass (imf30.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716339639; 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=vJ6RqBbexESHZQZG4h5ofX9X+/izj82ODYY/8DFDA3g=; b=PPDRe0NuI8ZIQoHRKNDndVlu4OKWiapPhUcJB7uQBcPCXmbrbyz2JeXI3qY7oTwq5Kb663 riu7TBrtbtHG8xfVQ+4gBHWF/Cp3vz0SeBW4P8fzXfncJS9szdeHwJXBHtU5hKXHGr9jeM 8ym3QD18Za6NdJE16cuDQOdtFuPM5Fw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716339639; a=rsa-sha256; cv=none; b=XfFH/+2hIQcxi6uRlhEgetUNGOYW4X3pkE/4mBTBsQVbCQLLC68pzP1WHoAceIGjSYh21V +oLestEsRIfAw0CDfkTn4KyvM4AJ5Ni/94SAPjOABQqzYhvkHAx8IFvvFsiI6bQabukjlv ugkO+O6/NgoBL6uisG0+L8yU3RNxHyc= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ThGATGNl; spf=pass (imf30.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 1F14562734; Wed, 22 May 2024 01:00:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67309C2BD11; Wed, 22 May 2024 01:00:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1716339637; bh=MhYuz5hxHwEcA/J213/XoPQ9yIK3Rf2PtgNf8nNBVMU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ThGATGNl5WdBJ6krO6ddFKa1Vi7Yud+Y+cNz7qeg8BLswYbqGv2hbq0COi3Ex+Ewr n2obnZQIZBYotClzBsXImUJrBjvivpy1hD8fu7Hu1SDIWwmQAH1syGKHP7wiBFkntK 1FvNODkFWUc5Sy8IajSK/gdRWpECSXMTqzikGCUUHiNymyfOTMZXMijrzHAqzuWEI1 pH2XExD+CQ4ccYEjCb8UslYH2GvgCaxPf8wngLj9shc/mmvhCZRbwikEGmNyQMNlRa VKSiL1LAk0eht4ivZdcrhabT5h7l+HBr+SinR4tUYmxC65yXomtTLO+DDXy2GBp1mo FV6G5hkWs+wRw== From: SeongJae Park To: Jonghyeon Kim Cc: SeongJae Park , damon@lists.linux.dev, linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 0/3] Add NUMA-aware DAMOS watermarks Date: Tue, 21 May 2024 18:00:34 -0700 Message-Id: <20240522010034.79165-1-sj@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240520143038.189061-1-tome01@ajou.ac.kr> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 2B96B8000E X-Rspam-User: X-Stat-Signature: 1b4x5sfbjyjc5sx5t7jcw5z4hkwkbcb1 X-HE-Tag: 1716339638-763011 X-HE-Meta: U2FsdGVkX19BXrYZCXoFXAsn8dgGr+/H1GZu0l21X31gzHGSvzpPUyw+LaDoJ/d41YZRQakaiW3m+IlUQaqlN1l473Yw//ccAVXGouE5tFSInNEq9R8BYD34xb+2AQ/4Zfhf3ROLTMzHarZvlyOFf3JQj3oxZSC5wzYIyu/7T0K902/Ak/dee5kROHX+Hu94QV+AYY0nCsJ/5SnBsDaWShzz6rmVhdX3c8rJi1+A4kxeVwdjLCGlYgC2MD4CX5RJ8BECuxiXbAW/F0tfGQR/5cMMIh8p+Ain3YqE8IC7mTyNXZDK3ePrWJtgtuGhyEnhmcdTv/Z3OaEMS/0Ni39vfIjeNzmHHMG7p7LwUVVAPjI76QiP7fYRpK89rAFmvtZ55QBhZp9hhYdFYTC2xWXe5PjimDthULSNGgxUXhBc4BPjfbB10xCqkYOlge7Oi0noGUrT2UxdfNVscqzlCtw6fgngGFPvKUA2oynF2cEl3ygMi5vGvMdyUAzDlf9k/cH1c1tnnV+oQmsC1CO9R9fvUh6rkVvrsJjKkdQ+E+abdX/WndfZwqKtD0PN8y8k1pzj99b+c5w8WfI+CRs/4tcoONgdDSkZPIxEwLQGAEoYqmcJvfJHq5ItTdcVHJOBo6ZW8bjoUCnQykx1cHpi7p0gy1+A0fildyl8yvB3kI8WHXU1j+2AZPEeXxvwCRjHd2MgXV3uDN6wE/9EWYtE2Tzcv+P8LdB+Yhm93YO72wyzXyooYiVxmC9VanGg/IBubjlQIErj1ehAeXEbKDewxhvZGDX/HUYcMFSoNt8ThT+TDwz3H38lexBwUIGglPlGQ7b0S58PuLw5WQbBi9fi6DIhu/ftvp24ZlPVy4rLZj9fj7nFt8UJxKtzNDJBP9MlSqvBG1Y+BRQN4sGM8kjoo0ALXGbJdycGrR0DFyu5vFBGOwM= 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: Hi Jonghyeon, On Mon, 20 May 2024 14:30:35 +0000 Jonghyeon Kim wrote: > Current DAMOS schemes are not considered with multiple NUMA memory nodes. > For example, If we want to proactively reclaim memory of a one NUMA node, > DAMON_RECLAIM has to wake up kdamond before kswapd does reclaim memory. > However, since the DAMON watermarks are based on not a one NUMA memory > node but total system free memory, kdamond is not waked up before invoking > memory reclamation from kswapd of the target node. > > These patches allow for DAMON to select monitoring target either total > memory or a specific NUMA memory node. I feel such usage could exist, but my humble brain is not clearly imagining such realistic usage. If you could further clarify the exampected usage, it would be very helpful for me to better understand the intention and pros/cons of this patchset. Especially, I'm wondering why they would want to use the watermark feature, rather than manually checking the metric and turning DAMON on/off, or feeding the metric as a quota tuning goal. > > --- > Changes from RFC PATCH v1 > (https://lore.kernel.org/all/20220218102611.31895-1-tome01@ajou.ac.kr) > - Add new metric type for NUMA node, DAMOS_WMARK_NODE_FREE_MEM_RATE > - Drop commit about damon_start() > - Support DAMON_LRU_SORT > > Jonghyeon Kim (3): > mm/damon: Add new metric type and target node for watermark > mm/damon: add module parameters for NUMA system > mm/damon: add NUMA-awareness to DAMON modules Following up to the above question, why they would want to use DAMON modules rather than manually controlling DAMON via DAMON sysfs interface? Thanks, SJ > > include/linux/damon.h | 11 +++++++++-- > mm/damon/core.c | 11 ++++++++--- > mm/damon/lru_sort.c | 14 ++++++++++++++ > mm/damon/modules-common.h | 4 +++- > mm/damon/reclaim.c | 14 ++++++++++++++ > mm/damon/sysfs-schemes.c | 35 +++++++++++++++++++++++++++++++++-- > 6 files changed, 81 insertions(+), 8 deletions(-) > > -- > 2.34.1