From: Kaixu Xia <[email protected]>
This patchset contains some code simplifications and cleanups
for DAMON.
Kaixu Xia (4):
mm/damon: simplify the parameter passing for 'prepare_access_checks'
mm/damon/sysfs: simplify the variable 'pid' assignment operation
mm/damon/core: simplify the kdamond stop mechanism by removing 'done'
mm/damon/vaddr: indicate the target is invalid when 'nr_regions' is
zero
mm/damon/core.c | 24 +++++++++---------------
mm/damon/paddr.c | 5 ++---
mm/damon/sysfs.c | 11 ++++-------
mm/damon/vaddr.c | 9 ++++++---
4 files changed, 21 insertions(+), 28 deletions(-)
--
2.27.0
From: Kaixu Xia <[email protected]>
When 'init()' and 'update()' DAMON operations failed and the number
of the damon_target regions is zero, 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 <[email protected]>
---
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
From: Kaixu Xia <[email protected]>
When the 'kdamond_wait_activation()' function or 'after_sampling()'
or 'after_aggregation()' DAMON callbacks return an error, it is
unnecessary to use bool 'done' to check if kdamond should be
finished. This commit simplifies the kdamond stop mechanism by
removing 'done' and break the while loop directly in the cases.
Signed-off-by: Kaixu Xia <[email protected]>
---
mm/damon/core.c | 24 +++++++++---------------
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/mm/damon/core.c b/mm/damon/core.c
index 0b1eb945c68a..4ce860af70ec 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -1165,30 +1165,25 @@ static int kdamond_fn(void *data)
struct damon_region *r, *next;
unsigned int max_nr_accesses = 0;
unsigned long sz_limit = 0;
- bool done = false;
pr_debug("kdamond (%d) starts\n", current->pid);
if (ctx->ops.init)
ctx->ops.init(ctx);
if (ctx->callback.before_start && ctx->callback.before_start(ctx))
- done = true;
+ goto done;
sz_limit = damon_region_sz_limit(ctx);
- while (!kdamond_need_stop(ctx) && !done) {
- if (kdamond_wait_activation(ctx)) {
- done = true;
- continue;
- }
+ while (!kdamond_need_stop(ctx)) {
+ if (kdamond_wait_activation(ctx))
+ break;
if (ctx->ops.prepare_access_checks)
ctx->ops.prepare_access_checks(ctx);
if (ctx->callback.after_sampling &&
- ctx->callback.after_sampling(ctx)) {
- done = true;
- continue;
- }
+ ctx->callback.after_sampling(ctx))
+ break;
kdamond_usleep(ctx->sample_interval);
@@ -1200,10 +1195,8 @@ static int kdamond_fn(void *data)
max_nr_accesses / 10,
sz_limit);
if (ctx->callback.after_aggregation &&
- ctx->callback.after_aggregation(ctx)) {
- done = true;
- continue;
- }
+ ctx->callback.after_aggregation(ctx))
+ break;
kdamond_apply_schemes(ctx);
kdamond_reset_aggregated(ctx);
kdamond_split_regions(ctx);
@@ -1217,6 +1210,7 @@ static int kdamond_fn(void *data)
sz_limit = damon_region_sz_limit(ctx);
}
}
+done:
damon_for_each_target(t, ctx) {
damon_for_each_region_safe(r, next, t)
damon_destroy_region(r, t);
--
2.27.0
On Tue, 13 Sep 2022 17:11:23 +0800 [email protected] wrote:
> From: Kaixu Xia <[email protected]>
>
> This patchset contains some code simplifications and cleanups
> for DAMON.
For the first three patches,
Reviewed-by: SeongJae Park <[email protected]>
But, I have a question for the last one. Please answer it.
Thanks,
SJ
>
> Kaixu Xia (4):
> mm/damon: simplify the parameter passing for 'prepare_access_checks'
> mm/damon/sysfs: simplify the variable 'pid' assignment operation
> mm/damon/core: simplify the kdamond stop mechanism by removing 'done'
> mm/damon/vaddr: indicate the target is invalid when 'nr_regions' is
> zero
>
> mm/damon/core.c | 24 +++++++++---------------
> mm/damon/paddr.c | 5 ++---
> mm/damon/sysfs.c | 11 ++++-------
> mm/damon/vaddr.c | 9 ++++++---
> 4 files changed, 21 insertions(+), 28 deletions(-)
>
> --
> 2.27.0
On Tue, 13 Sep 2022 17:11:27 +0800 [email protected] wrote:
> From: Kaixu Xia <[email protected]>
>
> 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?
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 <[email protected]>
> ---
> 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
On Tue, Sep 13, 2022 at 11:11 PM SeongJae Park <[email protected]> wrote:
>
> On Tue, 13 Sep 2022 17:11:27 +0800 [email protected] wrote:
>
> > From: Kaixu Xia <[email protected]>
> >
> > 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.
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 <[email protected]>
> > ---
> > 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
On Wed, Sep 14, 2022 at 4:04 PM SeongJae Park <[email protected]> wrote:
>
> On Wed, 14 Sep 2022 12:02:05 +0800 Kaixu Xia <[email protected]> wrote:
>
> > On Tue, Sep 13, 2022 at 11:11 PM SeongJae Park <[email protected]> wrote:
> > >
> > > On Tue, 13 Sep 2022 17:11:27 +0800 [email protected] wrote:
> > >
> > > > From: Kaixu Xia <[email protected]>
> > > >
> > > > 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?
>
That sounds reasonable. Thanks for your detailed explanation.
Thanks,
Kaixu
>
> 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 <[email protected]>
> > > > ---
> > > > 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
> >
On Wed, 14 Sep 2022 12:02:05 +0800 Kaixu Xia <[email protected]> wrote:
> On Tue, Sep 13, 2022 at 11:11 PM SeongJae Park <[email protected]> wrote:
> >
> > On Tue, 13 Sep 2022 17:11:27 +0800 [email protected] wrote:
> >
> > > From: Kaixu Xia <[email protected]>
> > >
> > > 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 <[email protected]>
> > > ---
> > > 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
>