linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: 杨欢 <link@vivo.com>
To: "SeongJae Park" <sj@kernel.org>, 杨欢 <link@vivo.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:DATA ACCESS MONITOR" <damon@lists.linux.dev>,
	"open list:DATA ACCESS MONITOR" <linux-mm@kvack.org>,
	opensource.kernel <opensource.kernel@vivo.com>
Subject: Re: [RFC 0/2] Damos filter cleanup code and implement workingset
Date: Fri, 22 Sep 2023 02:54:58 +0000	[thread overview]
Message-ID: <d060083d-ebdd-4966-9f41-87cef0d2c106@vivo.com> (raw)
In-Reply-To: <20230921193625.99617-1-sj@kernel.org>

HI SJ,

Thanks for your patient response.
> [Some people who received this message don't often get email from sj@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Huan,
>
>
> First of all, thank you for this patch.  I have some high level comments and
> questions as below.
>
> On Tue, 19 Sep 2023 17:52:33 +0800 Huan Yang <link@vivo.com> wrote:
>
>> Now damos support filter contains two type.
>> The first is scheme filter which will invoke each scheme apply,
>> second is scheme action filter, which will filter out unwanted action.
> IMHO, that's not clear definition of the types.  Conceptually, all the filters
> are same.  Nonetheless, they are having different behaviors because they are
> handled in different layer depending on which layer is more efficient to handle
Thanks for these instructions to help me understand the design idea of 
damos filter.
> those[1].
>
> I agree this is complicated and a bit verbose explanation, but I don't feel
> your scheme vs action definition is making it easier to understand.
>
>> But this implement is scattered in different implementations
> Indeed the implementation is scattered in core layer and the ops layer
> depending on the filter types.  But I think this is needed for efficient
> handling of those.

IMO, some simple filter can have a common implement, like anon filter? And,

for some special type, each layer offer their own?

>
>> and hard to reuse or extend.
>  From your first patch, which extending the filter, the essential change for the
> extension is adding another enum to 'enum damos_filter_type' (1 line) and
> addition of switch case in '__damos_pa_filter_out()' (3 lines).  I don't think
> it looks too complicated.  If you're saying it was hard to understand which
Yes, indeed.
> part really need to be modifed, I think that makes sense.  But in the case,
> we might need more comments rather than structural change.
>
>> This patchset clean up those filter code, move into filter.c and add header
>> to expose filter func.(patch 2)
> Again, I agree more code cleanup is needed.  But I'm not sure if this is the
> right way.  Especially, I'm unsure if it really need to have a dedicated file.

I think the filter code scatter into each layer may make code hard to 
reuse, other ops

may need anon filter or something. So, make code into a dedicated file 
may good?

(just my opinion.)

> To my humble eyes, it doesn't look like making code clearly easier to read
> compared to the current version.  This is probably because I don't feel your
> scheme vs action definition is clear to understand.  Neither it is
Yes, indeed, current code not clean, the idea didn't take shape.
> deduplicating code.  The patch adds lines more that deleted ones, according to
> its diffstat.  For the reason, I don't see clear benefit of this change.
In this code, maybe just a little benefit when other ops need to filter 
anon page? :)
>    I
> might be biased, having NIH (Not Invented Here) sindrome, or missing something.
> Please let me know if so.
>
>> And add a new filter "workingset" to protect workingset page.
> Can you explain expected use cases of this new filter type in more detail?
> Specifically, for what scheme action and under what situation this new filter

IMO, page if marked as workingset, mean page in task's core 
workload(maybe have

seen the refault, and trigger refault protect). So, for lru sort or reclaim,

we'd better not touch it?(If any wrong, please let me know.)

> type will be needed?  If you have some test data for the use case and could
> share it, it would be very helpful for me to understand why it is needed.

Sorry, this type just from my knowledge of MM, have no test data.

For futher learn of DAMON, I'll try it.

>
>> Do we need this and cleanup it?
> I think I cannot answer for now, and your further clarification and patient
> explanation could be helpful.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/tree/Documentation/mm/damon/design.rst?h=mm-everything-2023-09-20-19-38#n400
>
>
> Thanks,
> SJ

Thanks,

Huan

>
>> Huan Yang (2):
>>    mm/damos/filter: Add workingset page filter
>>    mm/damos/filter: Damos filter cleanup
>>
>>   include/linux/damon.h    |  62 +-----------------
>>   mm/damon/Makefile        |   2 +-
>>   mm/damon/core-test.h     |   7 ++
>>   mm/damon/core.c          |  93 ++++-----------------------
>>   mm/damon/filter.c        | 135 +++++++++++++++++++++++++++++++++++++++
>>   mm/damon/filter.h        | 119 ++++++++++++++++++++++++++++++++++
>>   mm/damon/paddr.c         |  29 +++------
>>   mm/damon/reclaim.c       |  48 +++++++++++---
>>   mm/damon/sysfs-schemes.c |   1 +
>>   9 files changed, 325 insertions(+), 171 deletions(-)
>>   create mode 100644 mm/damon/filter.c
>>   create mode 100644 mm/damon/filter.h
>>
>> --
>> 2.34.1
>>
>>


  reply	other threads:[~2023-09-22  2:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-19  9:52 Huan Yang
2023-09-19  9:52 ` [RFC 1/2] mm/damos/filter: Add workingset page filter Huan Yang
2023-09-19  9:52 ` [RFC 2/2] mm/damos/filter: Damos filter cleanup Huan Yang
2023-09-21 19:36 ` [RFC 0/2] Damos filter cleanup code and implement workingset SeongJae Park
2023-09-22  2:54   ` 杨欢 [this message]
2023-09-22 22:15     ` SeongJae Park
2023-09-25  2:10       ` 杨欢
2023-09-25 15:53         ` 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=d060083d-ebdd-4966-9f41-87cef0d2c106@vivo.com \
    --to=link@vivo.com \
    --cc=akpm@linux-foundation.org \
    --cc=damon@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=opensource.kernel@vivo.com \
    --cc=sj@kernel.org \
    /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