From: SeongJae Park <sj@kernel.org>
To: Honggyu Kim <honggyu.kim@sk.com>
Cc: SeongJae Park <sj@kernel.org>,
Simon Wang <wangchuanguo@inspur.com>,
kernel_team@skhynix.com,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
"david@redhat.com" <david@redhat.com>,
"mhocko@kernel.org" <mhocko@kernel.org>,
"zhengqi.arch@bytedance.com" <zhengqi.arch@bytedance.com>,
"shakeel.butt@linux.dev" <shakeel.butt@linux.dev>,
"lorenzo.stoakes@oracle.com" <lorenzo.stoakes@oracle.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"damon@lists.linux.dev" <damon@lists.linux.dev>
Subject: Re: [PATCH 2/2] mm/damon/sysfs-schemes: add use_nodes_of_tier on sysfs-schemes
Date: Mon, 9 Jun 2025 12:13:07 -0700 [thread overview]
Message-ID: <20250609191307.47928-1-sj@kernel.org> (raw)
In-Reply-To: <c75e8237-1411-4ac6-8def-f20c255f7e06@sk.com>
On Mon, 9 Jun 2025 21:39:50 +0900 Honggyu Kim <honggyu.kim@sk.com> wrote:
> Hi SeongJae and Simon,
>
> On 5/31/2025 4:40 AM, SeongJae Park wrote:
[...]
> > On Fri, 30 May 2025 08:04:42 +0000 Simon Wang (王传国) <wangchuanguo@inspur.com> wrote:
[...]
> > So, let's think about if your proposed change is an improvement. As the commit
> > 320080272892 is nicely explaining, I think that it is an improved behavior for
> > demotion. Actually it seems good behavior for promotion, too. But, the
> > behavior we are discussing here is not for the demotion but general migration
> > (specifically, DAMOS_MIGRATE_{HOT,COLD}).
> >
> > In my opinion, DAMOS_MIGRATE_{HOT,COLD} behavior should be somewhat similar to
> > that of move_pages() syscall, to make its behavior easy to expect. So I think
> > having commit 320080272892's behavior improvement to DAMOS_MIGRATE_{HOT,COLD}
> > is not a right thing to do.
> >
> > And this asks me a question. Is current DAMOS_MIGRATE_{HOT,COLD} behavior
> > similar to move_pages() syscall? Not really, since do_move_pages_to_node(),
> > which is called from move_pages() syscall and calls migrate_pages() is setting
> > mtc->nmask as NULL, while DAMOS_MIGRATE_{HOT,COLD} set it as NODE_MASK_NONE.
> >
> > Also, do_move_pages_to_node() uses alloc_migration_target() while
> > DAMOS_MIGRATE_{HOT,COLD} uses alloc_migrate_folio().
>
> I can see alloc_migrate_folio() also calls alloc_migration_target(), but do you
> mean alloc_migrate_folio() setting mtc->nmask to NULL is the difference?
Yes, and also alloc_migration_target()'s internal optimizations for demotion
use case.
Nonetheless, I'm saying about the differences between DAMOS_MIGRATE_{HOT,COLD}
and move_pages() behaviors in the bigger context.
>
> >
> > I overlooked this different behavior while reviewing this code, sorry. And I
> > don't think this difference is what we need to keep, unless there are good
> > rasons that well documented. Thank you for let us find this, Simon.
> >
> > So I suggest to set mtc->nmask as NULL, and use alloc_migration_target() from
> > __damon_pa_migrate_folio_list(), same to move_pages() system call. To use
> > alloc_migrate_folio() from __damon_pa_migrate_folio_list(), we renamed it from
> > alloc_demote_folio(), and made it none-static. If we use
> > alloc_migration_target() from __damon_pa_migrate_folio_list(), there is no
> > reason to keep the changes. Let's revert those too.
> >
> > Cc-ing Honggyu, who originally implemented the current behavior of
> > __damon_pa_migrate(). Honggyu, could you please let us know if the above
> > suggested changes are not ok for you?
> >
> > If Honggyu has no problem at the suggested change, Simon, would you mind doing
> > that? I can also make the patches. I don't really care who do that. I just
> > think someone should do that. This shouldn't be urgent real issue, in my
> > opinion, though.
I will send an RFC for this soon, to make discussions easier and unblocked.
Thanks,
SJ
[...]
next prev parent reply other threads:[~2025-06-09 19:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-30 8:04 Simon Wang (王传国)
2025-05-30 19:40 ` SeongJae Park
2025-06-03 3:05 ` wangchuanguo
2025-06-05 18:20 ` SeongJae Park
2025-06-09 12:39 ` Honggyu Kim
2025-06-09 19:13 ` SeongJae Park [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-05-29 3:12 Simon Wang (王传国)
2025-05-29 16:46 ` SeongJae Park
2025-05-28 11:10 [PATCH 0/2] add a knob to control whether to use other nodes at the same tier of the target node in DAMON wangchuanguo
2025-05-28 11:10 ` [PATCH 2/2] mm/damon/sysfs-schemes: add use_nodes_of_tier on sysfs-schemes wangchuanguo
2025-05-28 21:33 ` kernel test robot
2025-05-28 22:31 ` SeongJae Park
2025-06-09 12:30 ` Honggyu Kim
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=20250609191307.47928-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=honggyu.kim@sk.com \
--cc=kernel_team@skhynix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=wangchuanguo@inspur.com \
--cc=zhengqi.arch@bytedance.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox