From: SeongJae Park <sj@kernel.org>
To: xhao@linux.alibaba.com
Cc: sj@kernel.org, akpm@linux-foundation.org, damon@lists.linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3] mm/damon: Remove duplicate get_monitoring_region() definitions
Date: Thu, 8 Sep 2022 18:19:31 +0000 [thread overview]
Message-ID: <20220908181931.91994-1-sj@kernel.org> (raw)
In-Reply-To: <20220908022553.70745-1-xhao@linux.alibaba.com>
Hi Xin,
Thanks for your efforts! But, please answer to some more comments below.
> In lru_sort.c and reclaim.c, they are all defining get_monitoring_region()
> function, there is no need to define it separately.
>
> BTW, this patch removes two struct 'damon_lru_sort_ram_walk_arg' and
> 'damon_reclaim_ram_walk_arg', though the two structs are removed, if we
> want to add more fields to these structs for other purposes later, it will
> not too late for us to use them again.
> For example:
> struct damon_reclaim_ram_walk_arg {
> struct damon_addr_range raw_walk;
> xxx A;
> xxx B;
> }
> struct damon_lru_sort_ram_walk_arg {
> struct damon_addr_range raw_walk;
> xxx A;
> xxx B;
> }
Sorry, seems I didn't make my words clear enough. What I'm concerning[1] is,
any possible future change to 'struct damon_addr_range', not to
'struct damon_{reclaim,lru_sort}_ram_walk_arg'.
Also, after all, as mentioned before, the purpose of 'struct damon_addr_range'
is not saving the 'start' and 'end' fields of 'struct resource'. Let's use
different types for different purposes to avoid any unneeded dependencies.
[1] https://lore.kernel.org/damon/20220907172712.61006-1-sj@kernel.org/
>
> Signed-off-by: Xin Hao <xhao@linux.alibaba.com>
> ---
> include/linux/damon.h | 1 +
> mm/damon/core.c | 28 ++++++++++++++++++++++++++++
> mm/damon/lru_sort.c | 37 ++-----------------------------------
> mm/damon/reclaim.c | 37 ++-----------------------------------
> 4 files changed, 33 insertions(+), 70 deletions(-)
>
> diff --git a/include/linux/damon.h b/include/linux/damon.h
> index 7b1f4a488230..f27b92e5afc2 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h
> @@ -500,6 +500,7 @@ void damon_add_region(struct damon_region *r, struct damon_target *t);
> void damon_destroy_region(struct damon_region *r, struct damon_target *t);
> int damon_set_regions(struct damon_target *t, struct damon_addr_range *ranges,
> unsigned int nr_ranges);
> +bool damon_get_sram_monitoring_region(unsigned long *start, unsigned long *end);
>
> struct damos *damon_new_scheme(
> unsigned long min_sz_region, unsigned long max_sz_region,
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 7d25dc582fe3..05a2d1b9d03d 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -276,6 +276,34 @@ struct damos *damon_new_scheme(
> return scheme;
> }
>
> +static inline int walk_system_ram(struct resource *res, void *arg)
We will pass pointer to this function. I guess 'inline' makes no sense?
> +{
> + struct damon_addr_range *a = arg;
> +
> + if (a->end - a->start < resource_size(res)) {
> + a->start = res->start;
> + a->end = res->end;
> + }
> + return 0;
> +}
> +
> +/*
> + * Find biggest 'System RAM' resource and store its start and end address in
> + * @start and @end, respectively. If no System RAM is found, returns false.
> + */
> +bool damon_get_sram_monitoring_region(unsigned long *start, unsigned long *end)
We should avoid too verbose name, so 'sram' looks nice, but it might be able to
be more clear to let readers know what it does. For an example, how about
'damon_find_biggest_system_ram()'?
Below parts all look good.
Thanks,
SJ
[...]
next prev parent reply other threads:[~2022-09-08 18:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 2:25 [PATCH V3] mm/damon: Remove duplicate get_monitoring_region() definitions Xin Hao
2022-09-08 18:19 ` SeongJae Park [this message]
2022-09-09 2:10 ` haoxin
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=20220908181931.91994-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=xhao@linux.alibaba.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;
as well as URLs for NNTP newsgroup(s).