[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250620231324.99607-1-sj@kernel.org>
Date: Fri, 20 Jun 2025 16:13:24 -0700
From: SeongJae Park <sj@...nel.org>
To: Bijan Tabatabai <bijan311@...il.com>
Cc: SeongJae Park <sj@...nel.org>,
damon@...ts.linux.dev,
linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org,
david@...hat.com,
ziy@...dia.com,
matthew.brost@...el.com,
joshua.hahnjy@...il.com,
rakie.kim@...com,
byungchul@...com,
gourry@...rry.net,
ying.huang@...ux.alibaba.com,
apopple@...dia.com,
bijantabatab@...ron.com,
venkataravis@...ron.com,
emirakhur@...ron.com,
ajayjoshi@...ron.com,
vtavarespetr@...ron.com
Subject: Re: [RFC PATCH v2 0/2] mm/damon/paddr: Allow interleaving in migrate_{hot,cold} actions
On Fri, 20 Jun 2025 16:47:26 -0500 Bijan Tabatabai <bijan311@...il.com> wrote:
> Hi SeongJae,
>
> On Fri, Jun 20, 2025 at 3:21 PM SeongJae Park <sj@...nel.org> wrote:
> >
[...]
> > Also, even for general use case, I think such user-space intervention is not
> > too much request. Please let me know if I'm wrong.
>
> You are correct. The userspace tool would be coming up with the
> weights, so it would not be hard for it to write those weights to two
> places. I coupled the weights used in DAMON and weighted interleaving
> for this revision and the previous because I could not think of a use
> case where you would want to use different weights for allocation time
> and migration, so it felt silly to have two different places with the
> same data. However, I don't feel too strongly about this, so I'm
> willing to defer to your judgement.
Thank you for being kind and flexible about the decision. One such use case I
can think off the top of my head is when users want to do memory tiering, and
there are multiple nodes of same tier. For example, if users want to migrate
hot pages in a node to the upper tier, and there are multiple nodes for the
tier, users may want to do the migration with same weight, or in proportion to
their free space.
So let's push this way for now. Nothing is set on the stone, so please feel
free to let me know if you feel differently later.
>
> Also, our userspace tool updates these weights somewhat frequently,
> several times per minute, when it detects a change in the bandwidth
> utilization of the system to calibrate the interleave ratio. I am
> concerned about how frequent changes to the scheme via the sysfs
> interface will affect the effectiveness of DAMON's page sampling. From
> what I understand, updates to the sysfs aren't saved until the user
> writes to some sysfs file to commit them,
This is correct.
> then the damon context is
> recreated from scratch. Would this throw away all the previous sampling work
> done and work splitting and merging regions?
This is how an early version of DAMON sysfs interface was working. Your
concern was true for the version. Hence, we implemented online tuning
feature[1]. If you use DAMON user-space tool, 'damo tune'[2] is the command
for using this feature. So, as long as you use the feature, updating weights
several times per minute shouldn't make such issues.
[1] https://lore.kernel.org/20220429160606.127307-1-sj@kernel.org
[2] https://github.com/damonitor/damo/blob/next/USAGE.md#damo-tune
> I am not
> super familiar with how the sysfs interface interacts with the rest of
> the system, so this concern might be entirely unfounded, but I would
> appreciate some clarification here.
Thank you for asking. Please feel free to ask any more questions as you need!
[...]
> > This may require writing not small amount of code, especially for DAMON sysfs
> > interface. I think it is doable, though. If you don't mind, I'd like to
> > quickly make a prototype and share with you.
> >
> > What do you think?
>
> That sounds good to me! Having a prototype from you for the sysfs
> interface would certainly be helpful, but if you're busy, I can take a
> pass at it as well.
Great. I will try to do this by this weekend.
[...]
> Thank you for your help and feedback!
The pleasure if mine!
Thanks,
SJ
[...]
Powered by blists - more mailing lists