linux-kernel - Re: [PATCH V2] mm/damon: simplify scheme create in lru

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fd50c65c-728d-d561-afc1-6c1e2c73f252@linux.alibaba.com>
Date:   Thu, 15 Sep 2022 09:57:37 +0800
From:   haoxin <xhao@...ux.alibaba.com>
To:     SeongJae Park <sj@...nel.org>
Cc:     akpm@...ux-foundation.org, damon@...ts.linux.dev,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] mm/damon: simplify scheme create in lru_sort.c


在 2022/9/14 下午10:22, SeongJae Park 写道:
> Hi Xin,
>
> On Wed, 14 Sep 2022 19:38:59 +0800 Xin Hao <xhao@...ux.alibaba.com> wrote:
>
>> In damon_lru_sort_new_hot_scheme() and damon_lru_sort_new_cold_scheme(),
>> they have so much in common, so we can combine them into a single
>> function, and we just need to distinguish their differences.
> Thank you again for patiently waiting for my changes and reworking on this!
>
>> Signed-off-by: Xin Hao <xhao@...ux.alibaba.com>
>> ---
>>   mm/damon/lru_sort.c | 57 ++++++++++++++++++++++-----------------------
>>   1 file changed, 28 insertions(+), 29 deletions(-)
>>
>> diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
>> index 07a0908963fd..2eac907e866d 100644
>> --- a/mm/damon/lru_sort.c
>> +++ b/mm/damon/lru_sort.c
>> @@ -135,17 +135,40 @@ DEFINE_DAMON_MODULES_DAMOS_STATS_PARAMS(damon_lru_sort_cold_stat,
>>   static struct damon_ctx *ctx;
>>   static struct damon_target *target;
>>   
>> -static struct damos *damon_lru_sort_new_scheme(
>> -		struct damos_access_pattern *pattern, enum damos_action action)
>> +static struct damos *damon_lru_sort_new_scheme(unsigned int thres,
>> +					       enum damos_action action)
>>   {
>> +	struct damos_access_pattern pattern = {
>> +		/* Find regions having PAGE_SIZE or larger size */
>> +		.min_sz_region = PAGE_SIZE,
>> +		.max_sz_region = ULONG_MAX,
>> +		/* and accessed for more than the threshold */
> This comment would be better to be written again?
>
>> +		.min_nr_accesses = 0,
>> +		.max_nr_accesses = 0,
> If we're gonna set above two fields anyway later, we could simply remove above
> three lines.
>
>> +		/* no matter its age */
>> +		.min_age_region = 0,
>> +		.max_age_region = UINT_MAX,
>> +	};
>>   	struct damos_quota quota = damon_lru_sort_quota;
>>   
>>   	/* Use half of total quota for hot/cold pages sorting */
>>   	quota.ms = quota.ms / 2;
>>   
>> +	switch (action) {
>> +	case DAMOS_LRU_PRIO:
>> +		pattern.min_nr_accesses = thres;
>> +		pattern.max_nr_accesses = UINT_MAX;
>> +		break;
>> +	case DAMOS_LRU_DEPRIO:
>> +		pattern.min_age_region = thres;
>> +		break;
>> +	default:
>> +		return NULL;
>> +	}
>> +
> This switch-case makes me wondering if the 'default' case really possible case.
> I think it would be clearer to set these from caller.
>
> IMHO, it might be clearer and shorter to define a static global 'struct
> damos_access_pattern' stub variable, and make the
> damon_lru_sort_new_{hot,cold}_scheme() copies it to their local variable,
> update the relevant fields, and pass that to 'damon_new_scheme()'.  What do you
> think?
>
>>   	return damon_new_scheme(
>>   			/* find the pattern, and */
>> -			pattern,
>> +			&pattern,
>>   			/* (de)prioritize on LRU-lists */
>>   			action,
>>   			/* under the quota. */
>> @@ -157,37 +180,13 @@ static struct damos *damon_lru_sort_new_scheme(
>>   /* Create a DAMON-based operation scheme for hot memory regions */
>>   static struct damos *damon_lru_sort_new_hot_scheme(unsigned int hot_thres)
>>   {
>> -	struct damos_access_pattern pattern = {
>> -		/* Find regions having PAGE_SIZE or larger size */
>> -		.min_sz_region = PAGE_SIZE,
>> -		.max_sz_region = ULONG_MAX,
>> -		/* and accessed for more than the threshold */
>> -		.min_nr_accesses = hot_thres,
>> -		.max_nr_accesses = UINT_MAX,
>> -		/* no matter its age */
>> -		.min_age_region = 0,
>> -		.max_age_region = UINT_MAX,
>> -	};
>> -
>> -	return damon_lru_sort_new_scheme(&pattern, DAMOS_LRU_PRIO);
>> +	return damon_lru_sort_new_scheme(hot_thres, DAMOS_LRU_PRIO);
> If we follow what I suggested above, we could make this like below:
>
> 	struct damos_access_pattern pattern = damon_lru_sort_stub_access_pattern;
>
> 	pattern.min_nr_accesses = hot_thres;
> 	return damon_lru_sort_new_scheme(&pattern, DAMOS_LRU_PRIO);
Agree totally,  i will fix it in the next patch.
>>   }
>>   
>>   /* Create a DAMON-based operation scheme for cold memory regions */
>>   static struct damos *damon_lru_sort_new_cold_scheme(unsigned int cold_thres)
>>   {
>> -	struct damos_access_pattern pattern = {
>> -		/* Find regions having PAGE_SIZE or larger size */
>> -		.min_sz_region = PAGE_SIZE,
>> -		.max_sz_region = ULONG_MAX,
>> -		/* and not accessed at all */
>> -		.min_nr_accesses = 0,
>> -		.max_nr_accesses = 0,
>> -		/* for min_age or more micro-seconds */
>> -		.min_age_region = cold_thres,
>> -		.max_age_region = UINT_MAX,
>> -	};
>> -
>> -	return damon_lru_sort_new_scheme(&pattern, DAMOS_LRU_DEPRIO);
>> +	return damon_lru_sort_new_scheme(cold_thres, DAMOS_LRU_DEPRIO);
> And similarly here.
>
>>   }
>>   
>>   static int damon_lru_sort_apply_parameters(void)
>> -- 
>> 2.31.0
>>
>>
>
> Thanks,
> SJ