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 576B6C433EF for ; Mon, 7 Feb 2022 01:56:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 89E876B0072; Sun, 6 Feb 2022 20:56:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 84E5B6B0073; Sun, 6 Feb 2022 20:56:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C89D6B0074; Sun, 6 Feb 2022 20:56:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0099.hostedemail.com [216.40.44.99]) by kanga.kvack.org (Postfix) with ESMTP id 5A2756B0072 for ; Sun, 6 Feb 2022 20:56:23 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1014F8249980 for ; Mon, 7 Feb 2022 01:56:23 +0000 (UTC) X-FDA: 79114319046.28.12BACF2 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf04.hostedemail.com (Postfix) with ESMTP id 2354040004 for ; Mon, 7 Feb 2022 01:56:21 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id y9so3682841pjf.1 for ; Sun, 06 Feb 2022 17:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ajou.ac.kr; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Ns9nrjNUptIXwjY2mn7TbbkWxwvjecCtuZhyj8ZgjZ4=; b=ajDD3kAa4rYS4QDTFjBTnSqYnb/r8UsBS5F+ryGtPR/mtMFLANNOxKo4zYBq8ygPJl 94Wfsu6Ba4K4YtWRyr14DRjKtSUeRvh+Sa+6273bO1IukqjFAxdKwZp23djc77ahEF24 sm0x1aAJ8GZDHauDlrwBkznhwNm5MKZOJn75Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Ns9nrjNUptIXwjY2mn7TbbkWxwvjecCtuZhyj8ZgjZ4=; b=ZQ3FXkMCPNwImwiSH38Ahi/SrBF7HpDHyhMuoBhX37j1O/1rWQYsN6gI2JghYqJPKb 6Fj/ObblL2lefm6cI9BChJCF1UFmP8oSs1awW+GmpBU7675bdTWhTrd+JRHZ+5bj2kJT MtCzI8MmWnTN5CLPSaD6JUo8l/ORmL1Tx+rMCCVUe5ydjgbN8kefHaE3PNlx4z6iT1eI YPOyoIElmqbFAZ/6SpgIAy8sUgHWNNHaMk5gTKypPNJlQ/sZl7zK39XCL5wk18WKi192 IbI6qI8fnKhR6gRwEIBzuTa0Vg70Iqrk9D0/qd4uuzyrNa3EE5wcpwDSff4d9XbN3Rhk 8JbA== X-Gm-Message-State: AOAM53248sWoI3VP2JzYYS1n53QbbO+Jb4MXhBd/1+5VSWEK7Y3OdcZJ u1NhY37jZ2FKW5AcYmgClFmCjg== X-Google-Smtp-Source: ABdhPJyQSfXQRfnmdKsKDCeLrettCOmyX6eq5emkGZUWKlmjODQ36Vwkk0W8vKqKrOWYotOroo8xQg== X-Received: by 2002:a17:902:be11:: with SMTP id r17mr14858693pls.22.1644198980325; Sun, 06 Feb 2022 17:56:20 -0800 (PST) Received: from swarm08 ([210.107.197.32]) by smtp.gmail.com with ESMTPSA id lj3sm8519396pjb.37.2022.02.06.17.56.18 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sun, 06 Feb 2022 17:56:19 -0800 (PST) Date: Mon, 7 Feb 2022 10:56:16 +0900 From: Jonghyeon Kim To: David Rientjes Cc: Jonghyeon Kim , SeongJae Park , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/damon: Rebase DAMON_RECALIM watermarks for NUMA nodes Message-ID: <20220207015616.GA7661@swarm08> References: <20220204064059.6244-1-tome01@ajou.ac.kr> <20220204090642.2425-1-sj@kernel.org> <20220204110318.GA9391@swarm08> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 2354040004 X-Rspam-User: nil Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=ajou.ac.kr header.s=google header.b=ajDD3kAa; dmarc=pass (policy=reject) header.from=ajou.ac.kr; spf=pass (imf04.hostedemail.com: domain of tome01@ajou.ac.kr designates 209.85.216.43 as permitted sender) smtp.mailfrom=tome01@ajou.ac.kr X-Stat-Signature: jrxyzqeotzhhbd9ffhgzxeuptxjoikxj X-HE-Tag: 1644198981-485195 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: On Sun, Feb 06, 2022 at 02:28:18PM -0800, David Rientjes wrote: > On Fri, 4 Feb 2022, Jonghyeon Kim wrote: > > > > > This patch allows kdamond thread to select watermark options for monitoring > > > > specific node or whole system free memory. > > > > > > Why only specific NUMA node or whole system, instead of each NUMA node? Are > > > you running DARC for only specific NUMA node? If that's the case, I think > > > implementing your own DAMON-based policy in user space might be a better > > > choice. For example, you could implement and use a user-space daemon that > > > monitors free memory ratio of each NUMA node and adjusts the watermarks. > > > > > > > I have tested DAMON_RECLAIM for each NUMA node by using a module. But, I felt > > that the goal of DAMON_RECLAIM is dealing with the entire system memory or > > specific monitoring regions by using module parameters. So, I hoped to add more > > options for DAMON_RECLAIM on the NUMA system. > > > > Another thing I considered is the problem of correlation between NUMA node range > > and monitoring start/end addresses, such as "What if we monitor target that > > spans multiple nodes?". > > In that case, I guess we have to decide the policy for watermarks. > > > > > Hope I'm not making you get me wrong. You found the important limitation of > > > DAMON_RECLAIM, thank you! I really hope DAMON_RECLAIM to evolve to handle the > > > case. I'm just saying this patch looks like specialized for your special case, > > > and there could be a better approach for that. > > > > > > > If you agree that each NUMA node is able to have its own DAMON_RECLAIM daemon > > threads, I will add that codes in the next patch. > > > > It seems like one DAMON context per NUMA node is required for this, no? > Exactly, what I intend it. > In other words, since each context has its own set of memory regions that > it monitors and set of watermarks that it must abide by, if we want per > NUMA node proactive reclaim then each node must have its own context that > is coordinated by userspace if we want to do system-wide proactive > reclaim. Yes, that's why I was concerned about the correlation between the NUMA range and monitoring regions by userspace parameter. Therefore, I plan to add new parameters for per NUMA node proactive reclaim and specific monitoring target regions including system-wide proactive reclaim.