From: SeongJae Park <sj@kernel.org>
To: SeongJae Park <sj@kernel.org>
Cc: damon@lists.linux.dev, kernel-team@meta.com
Subject: Re: Two simple ideas for DAMON accuracy improvement
Date: Fri, 17 Jan 2025 17:47:06 -0800 [thread overview]
Message-ID: <20250118014706.76776-1-sj@kernel.org> (raw)
In-Reply-To: <20241026215311.148363-1-sj@kernel.org>
On Sat, 26 Oct 2024 14:53:11 -0700 SeongJae Park <sj@kernel.org> wrote:
> Hello DAMON community,
>
>
> There were a number of grateful questions, concerns, and improvement ideas
> around monitoring output accuracy of DAMON. I always admitted the fact that
> DAMON has many rooms for improvement, but was bit awary at changes for some
> reasons. Now I think it caused some unnecessarily long delay. Sorry about
> that. Now I want to invest some time on the topic. So starting by sharing
> below two simple ideas first.
>
> User-defined Regions Split Factor
> ---------------------------------
>
> DAMON's "Adasptive Regions Adjustment (ARA)" mechanism splits each region into
> randomly sized sub regions, show their access temperature, and merge back
> adjacent regions having similar temperature. The split factor is hard-coded as
> two. Increasing the number make DAMON regions more quickly converges in right
> shape. However, it makes number of DAMON regions in usual situation higher,
> and therefore induce more overhead. It will still keep the user-defined upper
> limit (max_nr_regions), though.
>
> The optimum value of the split factor would depend on the use case. We will
> therefore add another knob to let users set the factor on runtime. The default
> value will be two, so this will not introduce any regression or behavioral
> change to existing users.
>
> Periodic Fine-grain Split of Aged Regions
> -----------------------------------------
>
> If a region is continuously changing its boundary and access temperature, it
> means it is converging, or the access pattern of the workload is not
> stabilized. Either case, this is a healthy signal.
>
> If a region is consistently showing same access pattern for long time, it may
> because the access pattern is stabilized, and the region is correctly
> converged. However, it might be because the access pattern is changed, but the
> converging is slow.
>
> To avoid the too slow converging of aged regions, we will let users
> periodically increase the split factor for regions that kept current access
> pattern for long time (high 'age'). Users will be able to set the 'age'
> offset, the split factor for the aged regions, and time interval between the
> periodic fine-grain split of the regions. For example, users can ask DAMON to
> "split regions keeping current access pattern for ten minutes or higher to five
> sub-regions every minute".
>
> The feature will be ignored unless users explicitly set those, so that it does
> not introduce any regression of behavioral change to existing users.
>
> Discussions
> -----------
>
[...]
> I believe implementing the features would be not difficult. So unless someone
> voluntarily steps up, I will start implementation of the features, targeting
> v6.14 merge window.
TL; DR: The features will not be available by 6.14. Please make a voice if you
want the features get prioritized.
I still think the above features can be useful. But I was unable to make any
progress for those due to other prioritized works. Linux v6.14 may be released
on upcoming Sunday, so I don't think we can make it on it. Sorry if you were
waiting for the features.
It's also not clear if we will make it on the next major release. I'm now
trying to prioritize the monitoring intervals auto-tuning[1]. Please make your
voice if you want me to prioritize the development of the features, or step up
if you want to implement some of those on your own. I think the first feature
(user-defined regions split factor) could be a good DAMON-beginner's task.
[1] https://lore.kernel.org/20241202175459.2005526-1-sj@kernel.org
Thanks,
SJ
[...]
next prev parent reply other threads:[~2025-01-18 1:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-26 21:53 Two simple ideas for DAMON accuracy improvement SeongJae Park
2025-01-18 1:47 ` SeongJae Park [this message]
2025-02-13 22:23 ` SeongJae Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250118014706.76776-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=damon@lists.linux.dev \
--cc=kernel-team@meta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.