From: SeongJae Park <sj@kernel.org>
To: Kaixu Xia <xiakaixu1987@gmail.com>
Cc: SeongJae Park <sj@kernel.org>,
akpm@linux-foundation.org, damon@lists.linux.dev,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
Kaixu Xia <kaixuxia@tencent.com>
Subject: Re: [PATCH 4/4] mm/damon/vaddr: indicate the target is invalid when 'nr_regions' is zero
Date: Wed, 14 Sep 2022 08:04:04 +0000 [thread overview]
Message-ID: <20220914080404.58913-1-sj@kernel.org> (raw)
In-Reply-To: <CAGjdHu=8pGmyBpVMpf-V=6w7hZHLmG4WH5EsNchn_+GqikTDxQ@mail.gmail.com>
On Wed, 14 Sep 2022 12:02:05 +0800 Kaixu Xia <xiakaixu1987@gmail.com> wrote:
> On Tue, Sep 13, 2022 at 11:11 PM SeongJae Park <sj@kernel.org> wrote:
> >
> > On Tue, 13 Sep 2022 17:11:27 +0800 xiakaixu1987@gmail.com wrote:
> >
> > > From: Kaixu Xia <kaixuxia@tencent.com>
> > >
> > > When 'init()' and 'update()' DAMON operations failed and the number
> > > of the damon_target regions is zero,
> >
> > Well, I think that could be a temporal failure. In the case, later call of
> > 'update()' could success?
> >
> Yeah, the kdamond while() loop calls 'update()' periodically to fix this
> temporary failure. But for extreme scenarios that 'update()' continues to fail,
> we should have some ways to detect this case.
Even in the case, kdamond will do nothing but continuing the main loop while
sleeping sample_aggr interval (5ms by default) for each iteration, and calling
'update()' for every update interval (100ms by default). Waste is waste, but I
don't think that's a real issue. Further, continuous 'update()' failures mean
the process is in some weird state anyway, so I'd assume the process would be
finished soon. kdamond will also finish as soon as the process finishes.
Users could also find the strange situation (nothing in the monitoring results)
and finish kdamond on their own.
Anything I'm missing?
Andrew, I found you merged this patch in mm-unstable. Could you please hold it
until we finish this discussion?
Thanks,
SJ
>
> Thanks,
> Kaixu
> >
> > Thanks,
> > SJ
> >
> > > the kdamond would do nothing
> > > to this monitoring target in this case. It makes no sense to run
> > > kdamond when all of monitoring targets have no regions. So add the
> > > judgement in 'target_valid()' operation to indicate the target is
> > > invalid when 'nr_regions' is zero.
> >
> > >
> > > Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
> > > ---
> > > mm/damon/vaddr.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
> > > index 39ea48d9cc15..65ff98d49ec0 100644
> > > --- a/mm/damon/vaddr.c
> > > +++ b/mm/damon/vaddr.c
> > > @@ -598,6 +598,9 @@ static bool damon_va_target_valid(void *target)
> > > struct damon_target *t = target;
> > > struct task_struct *task;
> > >
> > > + if (!damon_nr_regions(t))
> > > + return false;
> > > +
> > > task = damon_get_task_struct(t);
> > > if (task) {
> > > put_task_struct(task);
> > > --
> > > 2.27.0
>
next prev parent reply other threads:[~2022-09-14 8:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-13 9:11 [PATCH 0/4] mm/damon: code simplifications and cleanups xiakaixu1987
2022-09-13 9:11 ` [PATCH 1/4] mm/damon: simplify the parameter passing for 'prepare_access_checks' xiakaixu1987
2022-09-13 9:11 ` [PATCH 2/4] mm/damon/sysfs: simplify the variable 'pid' assignment operation xiakaixu1987
2022-09-13 9:11 ` [PATCH 3/4] mm/damon/core: simplify the kdamond stop mechanism by removing 'done' xiakaixu1987
2022-09-13 9:11 ` [PATCH 4/4] mm/damon/vaddr: indicate the target is invalid when 'nr_regions' is zero xiakaixu1987
2022-09-13 15:11 ` SeongJae Park
2022-09-14 4:02 ` Kaixu Xia
2022-09-14 8:04 ` SeongJae Park [this message]
2022-09-14 8:21 ` Kaixu Xia
2022-09-13 15:12 ` [PATCH 0/4] mm/damon: code simplifications and cleanups 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=20220914080404.58913-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=kaixuxia@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=xiakaixu1987@gmail.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).