Question about the Purpose of DAMOS_FILTER_TYPE_YOUNG

[JongminKim-KU]

Hello, I'm Jongmin Kim from Korea University.

I have a question about the purpose of DAMOS_FILTER_TYPE_YOUNG.

From the discussion between HMSDK and DAMON developers, I understand that a new page-granular filter was suggested because DAMON's dynamic region-granularity monitoring might not be accurate [1]. However, there are already page-granular filters such as DAMON_FILTER_TYPE_ANON and DAMON_FILTER_TYPE_MEMCG [2]. Is it insufficient to apply these filters to pages in some cases?

Additionally, in the latest HMSDKv2.0, I'm wondering about the reason for using DAMON_FILTER_TYPE_YOUNG only with the "migrate_hot" action to improve accuracy and eventually avoid performance degradation, assuming high memory pressure in the high-tier node [3].

I would appreciate it if you could clarify any parts that I have misunderstood.

[1] https://lore.kernel.org/damon/20240118171756.80356-1-sj@kernel.org/ [2] https://lore.kernel.org/lkml/20240311204545.47097-1-sj@kernel.org/ [3] https://github.com/skhynix/hmsdk/commit/82634e8e7d8b0499210816fb5d6413cdc0e56be4

[hyeongtakji]

Hello Jongmin, thank you for your questions.

Is it insufficient to apply these filters to pages in some cases?

The purpose of DAMOS_FILTER_TYPE_YOUNG differs from DAMOS_FILTER_TYPE_ANON and DAMOS_FILTER_TYPE_MEMCG. While it is true that all of these filters operate at the page level, anon and memcg are used to categorize pages based on their characteristics. On the other hand, the young filter does the page-level access check. I think you might find this discussion [1] helpful.

I'm wondering about the reason for using DAMON_FILTER_TYPE_YOUNG only with the "migrate_hot" action...

As far as I know, the config file generated by gen_config.py contains DAMOS_FILTER_TYPE_YOUNG both for migrate_hot and migrate_cold. Their matching values are the opposite, though. I'm not really sure what made you wonder, but if there are any mistakes in the documentation please let us know.

[1] https://lore.kernel.org/all/20240429224451.67081-1-sj@kernel.org/

[JongminKim-KU]

I mistook the concept of the filter. Thank you for your kind response!

[honggyukim]

Hi @JongminKim-KU,

I've also mentioned that the way young filter works with matching and nomatching doesn't look straightforward but we didn't change it. You can get more info by reading the discussion at https://lore.kernel.org/damon/20240317083635.2085-1-honggyu.kim@sk.com.

Especially, I've drawn some ascii art in the following post. https://lore.kernel.org/damon/20240320070754.2165-1-honggyu.kim@sk.com

But the major misconception between @sjp38 and I was about the concept of filter. His concept of filter excludes things, but my concept of filter is applying something to the matched items by filter. DAMON uses excluding filter concept.

I hope this explanation is helpful to you.

[sj-aws]

Thank you for the kind explanation of the concept. Obviously the filter concept is not very straightforward to understand :sweat_smile: I'm thinking about making --damos_filter accepting more intuitive matching arguments. say, allow and disallow. For example, --damos_filter young allow will be same to --damos_filter young nomatching (filtering young pages in), and --damos_filter young disallow will be same to --damos_filter young matching (filtering young pages out). Maybe in/out are better than allow/disallow? Anyway, I made a GitHub issue for followup discussion of this: https://github.com/damonitor/damo/issues/1

[honggyukim]

Hi SeongJae, thanks for participating the discussion in our project!

I'm thinking about making --damos_filter accepting more intuitive matching arguments. say, allow and disallow. For example, --damos_filter young allow will be same to --damos_filter young nomatching (filtering young pages in), and --damos_filter young disallow will be same to --damos_filter young matching (filtering young pages out).

That could be feasible options but I would like to make it much simpler by adding --damos_matching_filter and this is a kind of pseudo filter that has the concept of including filter, which doesn't require kernel changes.

The way it works is as follows.

• --damos_matching_filter young
  • applying actions only to young pages
  • same as --damos_filter young nomatching
• --damos_matching_filter old
  • applying actions only to old pages
  • same as --damos_filter young matching

Unlike --damos_filter option, it doesn't receive matching/nomatching but just receives young/old.

This can be reused for memcg and other filters as well.

• e.g. --damos_filter memcg nomatching /hmsdk can be --damos_matching_filter memcg /hmsdk
  • This means apply damos actions only to PIDs under /hmsdk cgroup.

Maybe the name --damos_matching_filter can be renamed to --damos_infilter. We can also introduce --damos_nomatching_filter or --damos_outfilter likewise.

[honggyukim]

By reading the explanation at https://docs.kernel.org/mm/damon/design.html#damon-design-damos-filters, the option names could be --damos_filter_in or --damos_filter_out instead.

[honggyukim]

The usage can be simpler as follows.

• For demotion(migrate_cold), use --damos_filter_in old, which means migrate only old pages.
• For promotion(migrate_hot), use --damos_filter_in young, which means migrate only young pages.

[sjp38]

I'm a bit worrying that the discussion for making DAMOS filter easier to use is out of the scope of this issue. What about continuing the discussion on https://github.com/damonitor/damo/issues/1?

[honggyukim]

I've just left a comment based on your comment. My simple summary is as follows.

1. I now agree with excluding concept of DAMOS filter to avoid confusion when having multiple inclusion filters.
2. Let's make matching by default and omit it, but use not operator only for nomatching.

So I would like to make the usage as follows.

• --damos_action migrate_cold --damos_filter_out young: demote pages except young pages
• --damos_action migrate_hot --damos_filter_out not young: promote pages except not young pages