The 'enabled' will be incorrectly set because the 'system_wq'
might not initialized yet. This results in 'enabled=true',
but the 'damon_reclaim_timer' is inactive. So fix it by moving
the judgment logic of the 'damon_reclaim_initialized' to the
start position of the enable_store().
Fixes: 294928293813 ("mm/damon/reclaim: schedule 'damon_reclaim_timer' only after 'system_wq' is initialized")
Signed-off-by: Yuanzheng Song <[email protected]>
---
mm/damon/reclaim.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
index e69b807fefe4..b13d5a02bf2e 100644
--- a/mm/damon/reclaim.c
+++ b/mm/damon/reclaim.c
@@ -374,13 +374,14 @@ static bool damon_reclaim_initialized;
static int damon_reclaim_enabled_store(const char *val,
const struct kernel_param *kp)
{
- int rc = param_set_bool(val, kp);
-
- if (rc < 0)
- return rc;
+ int rc;
/* system_wq might not initialized yet */
if (!damon_reclaim_initialized)
+ return -EINVAL;
+
+ rc = param_set_bool(val, kp);
+ if (rc < 0)
return rc;
schedule_delayed_work(&damon_reclaim_timer, 0);
--
2.25.1
Hello Yuanzheng,
On Fri, 15 Jul 2022 06:16:09 +0000 Yuanzheng Song <[email protected]> wrote:
> The 'enabled' will be incorrectly set because the 'system_wq'
> might not initialized yet. This results in 'enabled=true',
> but the 'damon_reclaim_timer' is inactive. So fix it by moving
> the judgment logic of the 'damon_reclaim_initialized' to the
> start position of the enable_store().
Thank you for this patch!
In the case, however, 'damon_reclaim_init()' will activate
'damon_reclaim_timer', which will check the 'enabled' and start DAMON later.
So 'enabled' will inconsistently set while DAMON_RECLAIM is not really enabled
for a moment, but those will eventually be consistent. This patch could reduce
the duration of the inconsistent state.
However, this would break boot-time DAMON_RECLAIM enabling, which adds
'damon_reclaim.enabled=true' to the kernel parameter, as this change will set
'enabled' as 'false' in the early 'damon_reclaim_enabled_store()', so that the
later 'damon_reclaim_initialized()' activated 'damon_reclaim_timer' shows
'enabled' as 'false' and therefore doesn't start DAMON.
If there is anything I'm missing, please let me know.
Thanks,
SJ
>
> Fixes: 294928293813 ("mm/damon/reclaim: schedule 'damon_reclaim_timer' only after 'system_wq' is initialized")
> Signed-off-by: Yuanzheng Song <[email protected]>
> ---
> mm/damon/reclaim.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> index e69b807fefe4..b13d5a02bf2e 100644
> --- a/mm/damon/reclaim.c
> +++ b/mm/damon/reclaim.c
> @@ -374,13 +374,14 @@ static bool damon_reclaim_initialized;
> static int damon_reclaim_enabled_store(const char *val,
> const struct kernel_param *kp)
> {
> - int rc = param_set_bool(val, kp);
> -
> - if (rc < 0)
> - return rc;
> + int rc;
>
> /* system_wq might not initialized yet */
> if (!damon_reclaim_initialized)
> + return -EINVAL;
> +
> + rc = param_set_bool(val, kp);
> + if (rc < 0)
> return rc;
>
> schedule_delayed_work(&damon_reclaim_timer, 0);
> --
> 2.25.1
Hello SJ,
Thank you very much for your reply, through your reply let me understand
this principle, so please ignore this patch.
Thanks,
Yuanzheng
On 2022/7/16 1:07, SeongJae Park wrote:
> Hello Yuanzheng,
>
>
> On Fri, 15 Jul 2022 06:16:09 +0000 Yuanzheng Song <[email protected]> wrote:
>
>> The 'enabled' will be incorrectly set because the 'system_wq'
>> might not initialized yet. This results in 'enabled=true',
>> but the 'damon_reclaim_timer' is inactive. So fix it by moving
>> the judgment logic of the 'damon_reclaim_initialized' to the
>> start position of the enable_store().
> Thank you for this patch!
>
> In the case, however, 'damon_reclaim_init()' will activate
> 'damon_reclaim_timer', which will check the 'enabled' and start DAMON later.
> So 'enabled' will inconsistently set while DAMON_RECLAIM is not really enabled
> for a moment, but those will eventually be consistent. This patch could reduce
> the duration of the inconsistent state.
>
> However, this would break boot-time DAMON_RECLAIM enabling, which adds
> 'damon_reclaim.enabled=true' to the kernel parameter, as this change will set
> 'enabled' as 'false' in the early 'damon_reclaim_enabled_store()', so that the
> later 'damon_reclaim_initialized()' activated 'damon_reclaim_timer' shows
> 'enabled' as 'false' and therefore doesn't start DAMON.
>
> If there is anything I'm missing, please let me know.
>
>
> Thanks,
> SJ
>
>> Fixes: 294928293813 ("mm/damon/reclaim: schedule 'damon_reclaim_timer' only after 'system_wq' is initialized")
>> Signed-off-by: Yuanzheng Song <[email protected]>
>> ---
>> mm/damon/reclaim.c | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
>> index e69b807fefe4..b13d5a02bf2e 100644
>> --- a/mm/damon/reclaim.c
>> +++ b/mm/damon/reclaim.c
>> @@ -374,13 +374,14 @@ static bool damon_reclaim_initialized;
>> static int damon_reclaim_enabled_store(const char *val,
>> const struct kernel_param *kp)
>> {
>> - int rc = param_set_bool(val, kp);
>> -
>> - if (rc < 0)
>> - return rc;
>> + int rc;
>>
>> /* system_wq might not initialized yet */
>> if (!damon_reclaim_initialized)
>> + return -EINVAL;
>> +
>> + rc = param_set_bool(val, kp);
>> + if (rc < 0)
>> return rc;
>>
>> schedule_delayed_work(&damon_reclaim_timer, 0);
>> --
>> 2.25.1
> .