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 A25A3C47422 for ; Fri, 26 Jan 2024 08:05:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 362036B00CB; Fri, 26 Jan 2024 03:05:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 311736B00CC; Fri, 26 Jan 2024 03:05:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B39A6B00CD; Fri, 26 Jan 2024 03:05:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0475E6B00CB for ; Fri, 26 Jan 2024 03:05:01 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 955F4160122 for ; Fri, 26 Jan 2024 08:05:00 +0000 (UTC) X-FDA: 81720726360.09.0F151A9 Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by imf20.hostedemail.com (Postfix) with ESMTP id 1216C1C001B for ; Fri, 26 Jan 2024 08:04:58 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FxPsc1SH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of sj38.park@gmail.com designates 209.85.215.182 as permitted sender) smtp.mailfrom=sj38.park@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706256299; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:in-reply-to:references:dkim-signature; bh=PQZqXjnfMiJnpMoo1+KQWc+QVfHQsa7SqRJloMMoGq0=; b=iVhSxqp3xwK5Ew9MRpajaOO+4ByeBlIrXPbufJuwSHqPew47/jFLny3JOo5cser3VZsZQh oUA7AU0kTXRTPBRNKrbAZi4KdoSRJlU+mvz9dUfMUUlIUQ+I9eBTF3KvqV5cS3W1nCAcNJ llwQkmENWMtDAZyG+bEvLsy5ql0d1D0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FxPsc1SH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of sj38.park@gmail.com designates 209.85.215.182 as permitted sender) smtp.mailfrom=sj38.park@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706256299; a=rsa-sha256; cv=none; b=X4LPpBaEA+YfKgT/+LXom8/uEknaOOr9+16oNW2myd5QqlGPB9HTNhi43G78B7Ow066Cd/ CgtugNFhZBwdUGKPxeUxpyVGfP2ZYoUunWz9eMz0JyuOjgc5Kqk65iLQA54MxjhbLlqua+ knP2cWuvgyYs5pjlcSS+TA+4llP5kfQ= Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-5ce6b5e3c4eso41332a12.2 for ; Fri, 26 Jan 2024 00:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706256298; x=1706861098; darn=kvack.org; h=in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=PQZqXjnfMiJnpMoo1+KQWc+QVfHQsa7SqRJloMMoGq0=; b=FxPsc1SH6+gHESsv/2ilUKI0/9/DkrQOiOUInZzEkBHmn3RfuhhFW2T6i6mM/JA3b9 SEu4iXoI8/RWDBWHKyHPuqK3G9L/9wLaBMCLHEiqP3dWwKq8dHyHJ74NnqfLblk1edjM WS/+SbDmHGLVOFdwURx4UD6WsaInJUuQLz8t5zoY6PzLl5f07RRvLrBc4uW4kbpgeLkE UxxvvyegGH0EUOoyJd9Qn9qwocm15NAHTnpZS+LuR58haJpZ5muyZRG53gQ2Mgjt9qVb u1NwLmMnP/KkwpfKiozAh3TdVwgLdB3DhpKPD0TdBw7oS6tBe6I4B2IFpkWeC0W9kVV3 tTtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706256298; x=1706861098; h=in-reply-to:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=PQZqXjnfMiJnpMoo1+KQWc+QVfHQsa7SqRJloMMoGq0=; b=qG6RR1K1ri/7eZ83cf3usZ0yLpug45iTJ/S+xa50qmKS6cJA6ysinrtQlFhFllCcwC weU55+IZEUdWTd/u83q/AMHOZgA7TIh+a4yJTjuGGMqMokhtpqDG0QwTahc+hZzm+Co9 xukXxvq+7oKUFEagEHrdO+Vc6g4fItFCXDrRoq+TCPk0Y4qyAQah2a/C+0J8T/+M4AwV FetsjWX4LP9H/Od9XRwZXGnYhn8z/JYqwx/OugPvBui+e61VPhbAzj5qBABZZIvyM6z0 pljeuWkX8Zua3XN5kAbWggspI+NoUiriSMRqv01tvMr8cyJBzoF3etKMqfueMx3febeP 3yOQ== X-Gm-Message-State: AOJu0YwsR7107nFmyLZU1oWolekNwQcZC+WI1cjvKozKhMh/WAJ48nBV 8qprM1CFAPkHn9HTFgoGf/7E+EVaWbk2U9XS67mmmaRmMpDPcOsF X-Google-Smtp-Source: AGHT+IGfmbZKkJqn5DYHsnUB/HlbsSD4b7U+wcFk2saImSWOh/tYsOuUy6DJa89k+5XYyr7wqpmGTA== X-Received: by 2002:a17:90a:6fe2:b0:290:b29a:5258 with SMTP id e89-20020a17090a6fe200b00290b29a5258mr526348pjk.29.1706256297570; Fri, 26 Jan 2024 00:04:57 -0800 (PST) Received: from localhost.localdomain ([216.243.7.87]) by smtp.gmail.com with ESMTPSA id sk8-20020a17090b2dc800b00290701c8623sm669927pjb.28.2024.01.26.00.04.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jan 2024 00:04:56 -0800 (PST) From: SeongJae Park X-Google-Original-From: SeongJae Park To: cuiyangpei Cc: SeongJae Park , akpm@linux-foundation.org, damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, xiongping1@xiaom.com Subject: Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature Date: Fri, 26 Jan 2024 00:04:54 -0800 Message-Id: <20240126080454.15649-1-sj@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20240126065706.GA16652@cuiyangpei> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 1216C1C001B X-Stat-Signature: ybh9dg398aoie5bjqsq41aqqx4f8mi8h X-Rspam-User: X-HE-Tag: 1706256298-595061 X-HE-Meta: U2FsdGVkX19LtpyJHbEqHfcBH6gCq+lxXiqcatdwsNVS6By1mccH1FOv1rGW+ck/tTUo0nOTPs6qFr8PIwbdSJQ1vnGw4UasJbstti8U0Yk81Qo/xdbuQwk2nSAA+e8y1C7bWrG/fUAekcy89qlBw2HjmsOvX2TflW6QZ2nHmAjXH19FqIT1EWXhNnCWtNf5vsDmLQkfqlJj0Xbb9INZGJUS2qAmxBH9MHrCwu0OBAW0ieJUHXTYTlAm0/qcsDX2MIRXTJ2fSHdPJABEM1RjrCOSxW7dN0KIEQPuoQbaCED+Nzq7WoOjwcXfN1nO+5y0BCgo+YDn4wJvp45l65mXsniqbIDCAYGg5qS1jS9UUpndmQ+Llfm8n1EdzqS5vx3lnlx/O8EQ6cceXHY3tmH3nbrruHD593QPiXDRhZ/4MreqBMJA9I6gw9aabREVD10aAPjaOkQESBGApDnWlFvdQTx6LRf4DJpWo8tNopwJ7ae4q2Z4wetB0vjHeZO886BiCi/tLq2rHvqTA2WYr5HAXRAXIGsmjv1m1HqK3BKYH5SYQOdGp/tQWAwO7FBfx+BisiCkr5ji/5ttNSAR2KCJtn7RHGr/17NQRDM6s064GLrWhvj4Qs3HPuAaCAGvCYMjC1kM84Bi0xuaYeDcZZk+vPFGsAYpeCX9gux7ViExkEUJYTC+WGjKYmcAL6ebwVLvetoO5a8fg7QXNW05SwKwORdgrqep4R3jk1pHiP/O8tz4x7pob6EUN39tRLW2L5bxka2EuglmHV393DlYse3np9WETDi54WqiIP3qit11cmja/Sv68a1BcTP4BVRMRtn4p6HyEIH4D63BN+m/bfrfIrqTAHGUlIvdZBo5Q4Adpv0SDIL/sRkee1d9pMDzutg/+VrGv2/iS+dPHxr3GUoo87GBw1XgyOAJe5E4fUsvUU3JwVPVvE293zt5Zvq/ZrvybBt6lpgqB858rJ0J6ms V4bQNp41 tG/+M8iodJmkLShwDfuJG9AffaTEiacx6Gvgu/zkcnpDvRrEMZNUo95Aaj/jqtMPheJWH X-Bogosity: Ham, tests=bogofilter, spamicity=0.058951, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, 26 Jan 2024 14:57:06 +0800 cuiyangpei wrote: > On Mon, Jan 22, 2024 at 09:56:11AM -0800, SeongJae Park wrote: > > Hi cuiyangpei, > > > > On Mon, 22 Jan 2024 13:46:31 +0800 cuiyangpei wrote: > > > > > On Sun, Dec 03, 2023 at 07:37:45PM +0000, SeongJae Park wrote: > > > > On 2023-12-03T13:43:13+08:00 cuiyangpei wrote: > > > > > > > > > On Fri, Dec 01, 2023 at 05:31:12PM +0000, SeongJae Park wrote: > > > > > > Hi Cuiyangpei, > > > > > > > > > > > > On Fri, 1 Dec 2023 20:25:07 +0800 cuiyangpei wrote: > > > > > > > > > > > > > On Thu, Nov 30, 2023 at 07:44:20PM +0000, SeongJae Park wrote: > > > > > > > > Hi Cuiyangpei, > > > > > > > > > > > > > > > > On Thu, 30 Nov 2023 17:14:26 +0800 cuiyangpei wrote: [...] > > > Is there any way to catch sampling result immediately after setting the > > > "update_schemes_tried_regions" state? > > > > There is no way for exactly doing this. You would need to proactively collect > > snapshots while the app is foreground, and use the latest one that collected > > before the app goes background, like recording-based approach would do. > > > > I think recent DAMON changes might make an alternative approach available, > > though. From v6.7, DAMON provides pseudo-moving-average monitoring result in > > sampling interval granualrity, since patchset "mm/damon: provide pseudo-moving > > sum based access rate". And a followup patchset, namely "mm/damon: implement > > DAMOS apply intervals", has made DAMOS works in the sampling interval > > granualrity. Both patchsets are merged into v6.7-rc1. > > > > Hence, I think you could use 'update_schemes_tried_regions' after you noticed > > the app's state transition, with DAMOS apply interval of one sampling interval. > > Then you will get the monitoring results after one sampling interval. Of > > course, the snapshot may contain some of background access pattern, but > > wouldn't made it changed significantly, unless you set aggregation interval too > > short. > > All other actions will apply at one sampling interval except for the > `stat` action. > > We use 'update_schemes_tried_regions' after switch to the background. The > before_damos_apply callback function will only be set when the next aggregation > interval arrives. The `tried_regions` will only be updated after setting the > callback function. > > DAMON is still sampling during setting 'update_schemes_tried_regions' to the next > aggregation time, which is not what we expected. The pseudo-moving-average > monitoring result can reduce nr_accesees inaccuracy, but age is still being modified > during this time, so it can't improve this issue. > > Please let me know if my understanding is incorrect. Thank you. So, 'update_schemes_tried_regions' command is firstly handled by 'damon_sysfs_cmd_request_callback()', which is registered as after_wmarks_check() and after_aggregation() callback. Hence 'update_schemes_tried_regions' command is still effectively working in aggregation interval granularity. I think this is what you found, right? If I'm not wrongly understanding your point, I think the concern is valid. I think we should make it works in sampling interval granularity. I will try to make so. Would that work for your use case? > > > > > Alternatively, can it return the "last_nr_accesses" and "last_age" values in > > > tried_regions/ directory? > > > > This could also be a good alternative in my think. Nice idea. But, because > > the previously mentioned alternative is already available while this require a > > bit small but additional changes, could we check if the previously one make > > sense and works first? We could revisit this idea if it turns out the previous > > alternative is not suffice in my opinion. > > > Can you consider adding "last_nr_accesses" and "last_age" two files in > 'tried_regions/' directory? Actually we don't have 'last_age' field, right? And in case of 'last_nr_accesses', it is a hidden private field, since it is intended to be accessed by only DAMON core code. Making it exposed to user means exposing implementation details, and the mechanism that coupled with an exposed interface is hard to be changed, so be unflexible. Hence I'd prefer making 'update_schemes_tried_regions' works in sampling interval granularity, more than exposing the two information if it works for your use case. Thanks, SJ [...]