回复: [PATCH] mm: vmscan: export func:shrink_slab

["李培锋(wink)" <lipeifeng@oppo.com>]

>>> On 16.06.23 11:21, lipeifeng@oppo.com wrote:
>>> From: lipeifeng <lipeifeng@oppo.com>
>>> 
>>> Some of shrinkers during shrink_slab would enter synchronous-wait due 
>>> to lock or other reasons, which would causes kswapd or direct_reclaim 
>>> to be blocked.
>>> 
>>> This patch export shrink_slab so that it can be called in drivers 
>>> which can shrink memory independently.
>>> 
>>> Signed-off-by: lipeifeng <lipeifeng@oppo.com>
>>> ---
>>>   mm/vmscan.c | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/mm/vmscan.c b/mm/vmscan.c index 
>>> 6d0cd2840cf0..2e54fa52e7ec 100644
>>> --- a/mm/vmscan.c
>>> +++ b/mm/vmscan.c
>>> @@ -1043,7 +1043,7 @@ static unsigned long shrink_slab_memcg(gfp_t gfp_mask, int nid,
>>>    *
>>>    * Returns the number of reclaimed slab objects.
>>>    */
>>> -static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>>> +unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>>>   				 struct mem_cgroup *memcg,
>>>   				 int priority)
>>>   {
>>> @@ -1087,6 +1087,7 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>>>   	cond_resched();
>>>   	return freed;
>>>   }
>>> +EXPORT_SYMBOL_GPL(shrink_slab);
>>>   
>>>   static unsigned long drop_slab_node(int nid)
>>>   {
>>
>>It feels like something we don't want arbitrary drivers to call.
>>
>>Unrelated to that, this better be sent along with actual driver usage.
>
>Hi Sir：
>
>Virtually, we have implemented async shrink_slabd isolated from kswapd and direct_reclaim.
>The goal above it is to avoid the sync-wait in kswapd or direct_reclaim due to some shrinkers.
>
>But the async shrink_slabd was only applied to mobile products so that I didn't make sure any risk in other products. For the above reasons, I wanna merge the patch to export shrink_slab and the patch of drivers would be considered to be pushed if I check all the risks.
>
>Some informal code files of driver are attached for your reference.

Hi Sir:

Pls help to review the patch merge it if no problems, thanks you very much.

-----邮件原件-----
发件人: 李培锋(wink) 
发送时间: 2023年6月20日 11:05
收件人: David Hildenbrand <david@redhat.com>; akpm@linux-foundation.org
抄送: linux-mm@kvack.org; linux-kernel@vger.kernel.org; surenb@google.com; gregkh@google.com; zhangshiming@opp.com; 郭健 <guojian@oppo.com>
主题: 回复: [PATCH] mm: vmscan: export func:shrink_slab

On 16.06.23 11:21, lipeifeng@oppo.com wrote:
>> From: lipeifeng <lipeifeng@oppo.com>
>> 
>> Some of shrinkers during shrink_slab would enter synchronous-wait due 
>> to lock or other reasons, which would causes kswapd or direct_reclaim 
>> to be blocked.
>> 
>> This patch export shrink_slab so that it can be called in drivers 
>> which can shrink memory independently.
>> 
>> Signed-off-by: lipeifeng <lipeifeng@oppo.com>
>> ---
>>   mm/vmscan.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/mm/vmscan.c b/mm/vmscan.c index 
>> 6d0cd2840cf0..2e54fa52e7ec 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -1043,7 +1043,7 @@ static unsigned long shrink_slab_memcg(gfp_t gfp_mask, int nid,
>>    *
>>    * Returns the number of reclaimed slab objects.
>>    */
>> -static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>> +unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>>   				 struct mem_cgroup *memcg,
>>   				 int priority)
>>   {
>> @@ -1087,6 +1087,7 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>>   	cond_resched();
>>   	return freed;
>>   }
>> +EXPORT_SYMBOL_GPL(shrink_slab);
>>   
>>   static unsigned long drop_slab_node(int nid)
>>   {
>
>It feels like something we don't want arbitrary drivers to call.
>
>Unrelated to that, this better be sent along with actual driver usage.

Hi Sir：

Virtually, we have implemented async shrink_slabd isolated from kswapd and direct_reclaim.
The goal above it is to avoid the sync-wait in kswapd or direct_reclaim due to some shrinkers.

But the async shrink_slabd was only applied to mobile products so that I didn't make sure any risk in other products. For the above reasons, I wanna merge the patch to export shrink_slab and the patch of drivers would be considered to be pushed if I check all the risks.

Some informal code files of driver are attached for your reference.

-----邮件原件-----
发件人: David Hildenbrand <david@redhat.com>
发送时间: 2023年6月16日 17:43
收件人: 李培锋(wink) <lipeifeng@oppo.com>; akpm@linux-foundation.org
抄送: linux-mm@kvack.org; linux-kernel@vger.kernel.org; surenb@google.com; gregkh@google.com
主题: Re: [PATCH] mm: vmscan: export func:shrink_slab

On 16.06.23 11:21, lipeifeng@oppo.com wrote:
> From: lipeifeng <lipeifeng@oppo.com>
> 
> Some of shrinkers during shrink_slab would enter synchronous-wait due 
> to lock or other reasons, which would causes kswapd or direct_reclaim 
> to be blocked.
> 
> This patch export shrink_slab so that it can be called in drivers 
> which can shrink memory independently.
> 
> Signed-off-by: lipeifeng <lipeifeng@oppo.com>
> ---
>   mm/vmscan.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c index 
> 6d0cd2840cf0..2e54fa52e7ec 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1043,7 +1043,7 @@ static unsigned long shrink_slab_memcg(gfp_t gfp_mask, int nid,
>    *
>    * Returns the number of reclaimed slab objects.
>    */
> -static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
> +unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>   				 struct mem_cgroup *memcg,
>   				 int priority)
>   {
> @@ -1087,6 +1087,7 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>   	cond_resched();
>   	return freed;
>   }
> +EXPORT_SYMBOL_GPL(shrink_slab);
>   
>   static unsigned long drop_slab_node(int nid)
>   {

It feels like something we don't want arbitrary drivers to call.

Unrelated to that, this better be sent along with actual driver usage.

--
Cheers,

David / dhildenb