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 X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D373CC47082 for ; Mon, 7 Jun 2021 08:40:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 640AD60233 for ; Mon, 7 Jun 2021 08:40:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 640AD60233 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CF7776B006C; Mon, 7 Jun 2021 04:40:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CCE6B6B006E; Mon, 7 Jun 2021 04:40:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B47636B0070; Mon, 7 Jun 2021 04:40:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id 847326B006C for ; Mon, 7 Jun 2021 04:40:25 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 232858249980 for ; Mon, 7 Jun 2021 08:40:25 +0000 (UTC) X-FDA: 78226281210.06.7AB39FB Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) by imf15.hostedemail.com (Postfix) with ESMTP id D5C5BA000247 for ; Mon, 7 Jun 2021 08:40:22 +0000 (UTC) Received: by mail-qv1-f51.google.com with SMTP id g12so8387678qvx.12 for ; Mon, 07 Jun 2021 01:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to; bh=Gqfcx7MMX4ha2LKkgjhOiUBKHhgwQx6KDDCCsIrUgZU=; b=GjaPxKmzKDPnVhCAofZcL+gkEnpV0/IMVajsYB7vWEQxpG2pPoTWUolMbY24dUwvH2 iVh/y8CJjoa11A9m2p9GW2gsPNXyj7/u2IeYFgYDCcq5QIGh5taJ/Ez4qSSpiMJVlja4 cgg1nt6qQdF1yH+Pwk8w6fPJ5TXhVWP4TmhwXFTQ3Fs/LOfPeggczeeTvWR2d11NjiRq 2HKy1yyTilFIRKvZ2Fkmg1fO9f/dMLdroxfmcprp7SjtAszGau12h8lzZjZQs1B4Uc74 Tq/s0vjyonZP+0Ne8zxUPyT3E6wtTH9PHVyBinlfARrPhvb60g7IYdBUJHLsAoTbQeM/ N+pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to; bh=Gqfcx7MMX4ha2LKkgjhOiUBKHhgwQx6KDDCCsIrUgZU=; b=J8M4f7HwcJsgafP9lsGui1vaBQK0pcKlN6/iDqEV+B1AvOdqcUMU7sz0JsR0LnbCbc n/c9Xlkru4fs9xl//VBiTTz0Uo+SDtjO8XAVnjkCkm1WDYjJLb28TjDbl3Vyuq1Xtr+m 9txETFXIUwTQgANGZZWl23kRwUL1T0ngDB5S6ocKJWBb9hHzy1WxZU+4n3W1IOkvRfpJ giHKXOZaUMrYHby4snn1qqEj35cqWYY4Ncn62AboEUGPWV8Qcf52oBZMA+8Crq4wMUA2 uHGdZCBnj4LicutvFenKUHLWf/0swkuT3Jhd/+4uD/EMnH/KdAC3LpNR4Wj4yI+Wa1iV b+Zw== X-Gm-Message-State: AOAM531mT1rYxyV2dLzA8s+yfgI5sDetORPlYGCnhsNgBAXTgJYGwgHF ObklJ+cXhPd9KRX4pQ4/Q5E= X-Google-Smtp-Source: ABdhPJxzU9LINypXWHqu6BJOeLCjEzA6ggZHcJcyrTv/W0zBhQXZ+wr2E+0r+V4xvCA59ChcJd513g== X-Received: by 2002:a05:6214:11ac:: with SMTP id u12mr16644617qvv.15.1623055224084; Mon, 07 Jun 2021 01:40:24 -0700 (PDT) Received: from localhost.localdomain (ec2-35-169-212-159.compute-1.amazonaws.com. [35.169.212.159]) by smtp.gmail.com with ESMTPSA id x10sm2895496qkf.42.2021.06.07.01.40.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Jun 2021 01:40:23 -0700 (PDT) From: SeongJae Park X-Google-Original-From: SeongJae Park To: sj38.park@gmail.com Cc: jgowans@amazon.com, akpm@linux-foundation.org, SeongJae Park , Jonathan.Cameron@Huawei.com, acme@kernel.org, alexander.shishkin@linux.intel.com, amit@kernel.org, benh@kernel.crashing.org, brendanhiggins@google.com, corbet@lwn.net, david@redhat.com, dwmw@amazon.com, elver@google.com, fan.du@intel.com, foersleo@amazon.de, greg@kroah.com, gthelen@google.com, guoju.fgj@alibaba-inc.com, mgorman@suse.de, minchan@kernel.org, mingo@redhat.com, namhyung@kernel.org, peterz@infradead.org, riel@surriel.com, rientjes@google.com, rostedt@goodmis.org, rppt@kernel.org, shakeelb@google.com, shuah@kernel.org, snu@zelle79.org, vbabka@suse.cz, vdavydov.dev@gmail.com, zgf574564920@gmail.com, linux-damon@amazon.com, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 10/13] mm/damon/schemes: Activate schemes based on a watermarks mechanism Date: Mon, 7 Jun 2021 08:40:15 +0000 Message-Id: <20210607084015.1620-1-sjpark@amazon.de> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20210531133816.12689-11-sj38.park@gmail.com> Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=GjaPxKmz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of sj38park@gmail.com designates 209.85.219.51 as permitted sender) smtp.mailfrom=sj38park@gmail.com X-Stat-Signature: ossjsoekromx1bmnwmafupnnsgyiomw4 X-Rspamd-Queue-Id: D5C5BA000247 X-Rspamd-Server: rspam02 X-HE-Tag: 1623055222-249298 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: From: SeongJae Park On Mon, 31 May 2021 13:38:13 +0000 sj38.park@gmail.com wrote: > From: SeongJae Park > > DAMON-based operation schemes need to be manually turned on and off. In > some use cases, however, the condition for turning a scheme on and off > would depend on the system's situation. For example, schemes for > proactive pages reclamation would need to be turned on when some memory > pressure is detected, and turned off when the system has enough free > memory. > > For easier control of schemes activation based on the system situation, > this commit introduces a watermarks-based mechanism. The client can > describe the watermark metric (e.g., amount of free memory in the > system), watermark check interval, and three watermarks, namely high, > mid, and low. If the scheme is deactivated, it only gets the metric and > compare that to the three watermarks for every check interval. If the > metric is higher than the high watermark, the scheme is deactivated. If > the metric is between the mid watermark and the low watermark, the > scheme is activated. If the metric is lower than the low watermark, the > scheme is deactivated again. This is to allow users fall back to > traditional page-granularity mechanisms. > > Signed-off-by: SeongJae Park > --- > include/linux/damon.h | 52 +++++++++++++++++++++++++- > mm/damon/core.c | 87 ++++++++++++++++++++++++++++++++++++++++++- > mm/damon/dbgfs.c | 5 ++- > 3 files changed, 141 insertions(+), 3 deletions(-) > > diff --git a/include/linux/damon.h b/include/linux/damon.h > index 565f49d8ba44..2edd84e98056 100644 > --- a/include/linux/damon.h > +++ b/include/linux/damon.h > @@ -127,6 +127,45 @@ struct damos_speed_limit { > unsigned int min_score; > }; [...] > static void set_kdamond_stop(struct damon_ctx *ctx) > { > mutex_lock(&ctx->kdamond_lock); > @@ -904,6 +982,13 @@ static int kdamond_fn(void *data) > sz_limit = damon_region_sz_limit(ctx); > > while (!kdamond_need_stop(ctx)) { > + unsigned long wmark_wait_us = kdamond_wmark_wait_us(ctx); > + > + if (wmark_wait_us) { > + usleep_range(wmark_wait_us, wmark_wait_us + 1); > + continue; > + } James Gowans (jgowans@amazon.com) found this will make kdamond sleeps in TASK_UNINTERRUPTIBLE state. So, when DAMON is deactivated due to the watermarks rule, the sysadmin assumes it would do nothing and DAMON really do nothing. But, because it's sleeping in TASK_UNINTERRUPTIBLE state, which is usually interpreted as waiting for I/O, '/proc/loadavg' like monitors will report I/O loads, so that the sysadmin get confused. In the next version of this RFC patchset, I will make this to use 'schedule_timeout_interruptible()' instead, if 'wmark_wait_us' is larger than 100ms. I will continue using 'usleep_range()' for small sleep time, to keep the precision high. Thanks, SeongJae Park [...]