[RFC/Discussion] mm/damon: Implementation for paused kdamond

[RFC/Discussion] mm/damon: Implementation for paused kdamond

[Liew Rui Yan]

Hi SJ,

I noticed that the current implementation for paused kdamond is
periodically applies online parameter updates by kdamond_usleep().

I'd like to know if we should change it to waitqueue to achieve a lower
power consumption?

Previous Discussion
===================

I noticed that when you introduced ctx->pause [1], Sashiko asked the
same question, and your response at the time was:

    "sample internval is 5ms by default and recommended auto-tuning
    setup makes it hundreds of milliseconds.  So I don't think such
    change is required."

I'm curious that, did you think it wasn't neccessary to change it to
waitqueue when it was introduced, or it wasn't neccessary to do so even
after it had been introduced?

Asussmption
===========

This is just my assumption, not a real use case I knew:  When 'pause' is
set on an Android device, user might want DAMON to stop running
completely when the screen is off, thereby reducing the load on the CPU
without losing important information such as regions and age.

The current polling may make it harder for the phone to enter idle mode,
resulting in some unnecessary power consumption.

However, pause feature is only present in the stable version v7.2 or
higher, and since the latest Android kernel is 6.18, this highly
unlikely will affect any Android users.

[1] https://lore.kernel.org/damon/20260321202858.98091-1-sj@kernel.org

Best regards,
Rui Yan

Re: [RFC/Discussion] mm/damon: Implementation for paused kdamond

[SJ Park]

On Mon, 14 Sep 2026 23:35:10 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> Hi SJ,
> 
> I noticed that the current implementation for paused kdamond is
> periodically applies online parameter updates by kdamond_usleep().
> 
> I'd like to know if we should change it to waitqueue to achieve a lower
> power consumption?

I'd like to make a data driven decision :)

> 
> Previous Discussion
> ===================
> 
> I noticed that when you introduced ctx->pause [1], Sashiko asked the
> same question, and your response at the time was:
> 
>     "sample internval is 5ms by default and recommended auto-tuning
>     setup makes it hundreds of milliseconds.  So I don't think such
>     change is required."
> 
> I'm curious that, did you think it wasn't neccessary to change it to
> waitqueue when it was introduced, or it wasn't neccessary to do so even
> after it had been introduced?

I guess I thought so when the quiestion is raised.

> 
> Asussmption
> ===========
> 
> This is just my assumption, not a real use case I knew:  When 'pause' is
> set on an Android device, user might want DAMON to stop running
> completely when the screen is off, thereby reducing the load on the CPU
> without losing important information such as regions and age.
> 
> The current polling may make it harder for the phone to enter idle mode,
> resulting in some unnecessary power consumption.
> 
> However, pause feature is only present in the stable version v7.2 or
> higher, and since the latest Android kernel is 6.18, this highly
> unlikely will affect any Android users.

If whoever comes with a data that require changes, we can discuss.

> 
> [1] https://lore.kernel.org/damon/20260321202858.98091-1-sj@kernel.org


Thanks,
SJ

[...]

Re: [RFC/Discussion] mm/damon: Implementation for paused kdamond

[Liew Rui Yan]

On Mon, 14 Sep 2026 17:28:35 -0700 SJ Park <sj@kernel.org> wrote:

> On Mon, 14 Sep 2026 23:35:10 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
> 
> > Hi SJ,
> > 
> > I noticed that the current implementation for paused kdamond is
> > periodically applies online parameter updates by kdamond_usleep().
> > 
> > I'd like to know if we should change it to waitqueue to achieve a lower
> > power consumption?
> 
> I'd like to make a data driven decision :)
> 
> > 
> > Previous Discussion
> > ===================
> > 
> > I noticed that when you introduced ctx->pause [1], Sashiko asked the
> > same question, and your response at the time was:
> > 
> >     "sample internval is 5ms by default and recommended auto-tuning
> >     setup makes it hundreds of milliseconds.  So I don't think such
> >     change is required."
> > 
> > I'm curious that, did you think it wasn't neccessary to change it to
> > waitqueue when it was introduced, or it wasn't neccessary to do so even
> > after it had been introduced?
> 
> I guess I thought so when the quiestion is raised.
> 
> > 
> > Asussmption
> > ===========
> > 
> > This is just my assumption, not a real use case I knew:  When 'pause' is
> > set on an Android device, user might want DAMON to stop running
> > completely when the screen is off, thereby reducing the load on the CPU
> > without losing important information such as regions and age.
> > 
> > The current polling may make it harder for the phone to enter idle mode,
> > resulting in some unnecessary power consumption.
> > 
> > However, pause feature is only present in the stable version v7.2 or
> > higher, and since the latest Android kernel is 6.18, this highly
> > unlikely will affect any Android users.
> 
> If whoever comes with a data that require changes, we can discuss.

Thank you for your clarify.

I recently backported the pause feature to my phone.  However, due to
Android's screen-off mechanisms, I wasn't able to obtain any valid data
during testing.

Since we haven't identified any practical issues with the existing pause
feature, switching to waitqueue isn't neccessary at this time.

Regarding the documentation, should we explicitly explain the
relationship between 'pause' and sample_interval in the documentation?
That way, users can adjust the sample_interval value when using pause
feature based on their specific use case.

> 
> > 
> > [1] https://lore.kernel.org/damon/20260321202858.98091-1-sj@kernel.org

Best regards,
Rui Yan

Re: [RFC/Discussion] mm/damon: Implementation for paused kdamond

[SeongJae Park]

On Thu, 17 Sep 2026 23:31:53 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> On Mon, 14 Sep 2026 17:28:35 -0700 SJ Park <sj@kernel.org> wrote:
> 
> > On Mon, 14 Sep 2026 23:35:10 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
> > 
> > > Hi SJ,
> > > 
> > > I noticed that the current implementation for paused kdamond is
> > > periodically applies online parameter updates by kdamond_usleep().
> > > 
> > > I'd like to know if we should change it to waitqueue to achieve a lower
> > > power consumption?
> > 
> > I'd like to make a data driven decision :)
> > 
> > > 
> > > Previous Discussion
> > > ===================
> > > 
> > > I noticed that when you introduced ctx->pause [1], Sashiko asked the
> > > same question, and your response at the time was:
> > > 
> > >     "sample internval is 5ms by default and recommended auto-tuning
> > >     setup makes it hundreds of milliseconds.  So I don't think such
> > >     change is required."
> > > 
> > > I'm curious that, did you think it wasn't neccessary to change it to
> > > waitqueue when it was introduced, or it wasn't neccessary to do so even
> > > after it had been introduced?
> > 
> > I guess I thought so when the quiestion is raised.
> > 
> > > 
> > > Asussmption
> > > ===========
> > > 
> > > This is just my assumption, not a real use case I knew:  When 'pause' is
> > > set on an Android device, user might want DAMON to stop running
> > > completely when the screen is off, thereby reducing the load on the CPU
> > > without losing important information such as regions and age.
> > > 
> > > The current polling may make it harder for the phone to enter idle mode,
> > > resulting in some unnecessary power consumption.
> > > 
> > > However, pause feature is only present in the stable version v7.2 or
> > > higher, and since the latest Android kernel is 6.18, this highly
> > > unlikely will affect any Android users.
> > 
> > If whoever comes with a data that require changes, we can discuss.
> 
> Thank you for your clarify.
> 
> I recently backported the pause feature to my phone.  However, due to
> Android's screen-off mechanisms, I wasn't able to obtain any valid data
> during testing.
> 
> Since we haven't identified any practical issues with the existing pause
> feature, switching to waitqueue isn't neccessary at this time.

Thank you for checking this.  I agree.

> 
> Regarding the documentation, should we explicitly explain the
> relationship between 'pause' and sample_interval in the documentation?
> That way, users can adjust the sample_interval value when using pause
> feature based on their specific use case.

I think that is too much detail for normal users, unless we find a problem from
the lack of the documentation.


Thanks,
SJ

[...]

Re: [RFC/Discussion] mm/damon: Implementation for paused kdamond

[Liew Rui Yan]

On Thu, 17 Sep 2026 19:45:06 -0700 SeongJae Park <sj@kernel.org> wrote:

> On Thu, 17 Sep 2026 23:31:53 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
> 
> > On Mon, 14 Sep 2026 17:28:35 -0700 SJ Park <sj@kernel.org> wrote:
> > 
> > > On Mon, 14 Sep 2026 23:35:10 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
> > > 
> > > > Hi SJ,
> > > > 
> > > > I noticed that the current implementation for paused kdamond is
> > > > periodically applies online parameter updates by kdamond_usleep().
> > > > 
> > > > I'd like to know if we should change it to waitqueue to achieve a lower
> > > > power consumption?
> > > 
> > > I'd like to make a data driven decision :)
> > > 
> > > > 
> > > > Previous Discussion
> > > > ===================
> > > > 
> > > > I noticed that when you introduced ctx->pause [1], Sashiko asked the
> > > > same question, and your response at the time was:
> > > > 
> > > >     "sample internval is 5ms by default and recommended auto-tuning
> > > >     setup makes it hundreds of milliseconds.  So I don't think such
> > > >     change is required."
> > > > 
> > > > I'm curious that, did you think it wasn't neccessary to change it to
> > > > waitqueue when it was introduced, or it wasn't neccessary to do so even
> > > > after it had been introduced?
> > > 
> > > I guess I thought so when the quiestion is raised.
> > > 
> > > > 
> > > > Asussmption
> > > > ===========
> > > > 
> > > > This is just my assumption, not a real use case I knew:  When 'pause' is
> > > > set on an Android device, user might want DAMON to stop running
> > > > completely when the screen is off, thereby reducing the load on the CPU
> > > > without losing important information such as regions and age.
> > > > 
> > > > The current polling may make it harder for the phone to enter idle mode,
> > > > resulting in some unnecessary power consumption.
> > > > 
> > > > However, pause feature is only present in the stable version v7.2 or
> > > > higher, and since the latest Android kernel is 6.18, this highly
> > > > unlikely will affect any Android users.
> > > 
> > > If whoever comes with a data that require changes, we can discuss.
> > 
> > Thank you for your clarify.
> > 
> > I recently backported the pause feature to my phone.  However, due to
> > Android's screen-off mechanisms, I wasn't able to obtain any valid data
> > during testing.
> > 
> > Since we haven't identified any practical issues with the existing pause
> > feature, switching to waitqueue isn't neccessary at this time.
> 
> Thank you for checking this.  I agree.
> 
> > 
> > Regarding the documentation, should we explicitly explain the
> > relationship between 'pause' and sample_interval in the documentation?
> > That way, users can adjust the sample_interval value when using pause
> > feature based on their specific use case.
> 
> I think that is too much detail for normal users, unless we find a problem from
> the lack of the documentation.

All right, since no normal users seems confused by how the pause feature
works right now, add documentation isn't necessary at this time.  Thank
you for your guidance.

Best regards,
Rui Yan