Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1658757 > unrolled thread

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure zhong jiang <zhongjiang@huawei.com> - 2017-06-06 15:10 +0200
    Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure zhong jiang <zhongjiang@huawei.com> - 2017-06-07 05:10 +0200
    Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure Minchan Kim <minchan@kernel.org> - 2017-06-07 05:10 +0200

#1658757 — Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

On 2017/1/31 7:40, Minchan Kim wrote:
> Hi Vinayak,
> Sorry for late response. It was Lunar New Year holidays.
>
> On Fri, Jan 27, 2017 at 01:43:23PM +0530, vinayak menon wrote:
>>> Thanks for the explain. However, such case can happen with THP page
>>> as well as slab. In case of THP page, nr_scanned is 1 but nr_reclaimed
>>> could be 512 so I think vmpressure should have a logic to prevent undeflow
>>> regardless of slab shrinking.
>>>
>> I see. Going to send a vmpressure fix. But, wouldn't the THP case
>> result in incorrect
>> vmpressure reporting even if we fix the vmpressure underflow problem ?
> If a THP page is reclaimed, it reports lower pressure due to bigger
> reclaim ratio(ie, reclaimed/scanned) compared to normal pages but
> it's not a problem, is it? Because VM reclaimed more memory than
> expected so memory pressure isn't severe now.
  Hi, Minchan

  THP lru page is reclaimed, reclaim ratio bigger make sense. but I read the code, I found
  THP is split to normal pages and loop again.  reclaimed pages should not be bigger
   than nr_scan.  because of each loop will increase nr_scan counter.
 
   It is likely  I miss something.  you can point out the point please.
 
  Thanks
  zhongjiang
>>>>>> unsigned arithmetic results in the pressure value to be
>>>>>> huge, thus resulting in a critical event being sent to
>>>>>> root cgroup. Fix this by not passing the reclaimed slab
>>>>>> count to vmpressure, with the assumption that vmpressure
>>>>>> should show the actual pressure on LRU which is now
>>>>>> diluted by adding reclaimed slab without a corresponding
>>>>>> scanned value.
>>>>> I can't guess justfication of your assumption from the description.
>>>>> Why do we consider only LRU pages for vmpressure? Could you elaborate
>>>>> a bit?
>>>>>
>>>> When we encountered the false events from vmpressure, thought the problem
>>>> could be that slab scanned is not included in sc->nr_scanned, like it is done
>>>> for reclaimed. But later thought vmpressure works only on the scanned and
>>>> reclaimed from LRU. I can explain what I understand, let me know if this is
>>>> incorrect.
>>>> vmpressure is an index which tells the pressure on LRU, and thus an
>>>> indicator of thrashing. In shrink_node when we come out of the inner do-while
>>>> loop after shrinking the lruvec, the scanned and reclaimed corresponds to the
>>>> pressure felt on the LRUs which in turn indicates the pressure on VM. The
>>>> moment we add the slab reclaimed pages to the reclaimed, we dilute the
>>>> actual pressure felt on LRUs. When slab scanned/reclaimed is not included
>>>> in the vmpressure, the values will indicate the actual pressure and if there
>>>> were a lot of slab reclaimed pages it will result in lesser pressure
>>>> on LRUs in the next run which will again be indicated by vmpressure. i.e. the
>>> I think there is no intention to exclude slab by design of vmpressure.
>>> Beause slab is memory consumption so freeing of slab pages really helps
>>> the memory pressure. Also, there might be slab-intensive workload rather
>>> than LRU. It would be great if vmpressure works well with that case.
>>> But the problem with involving slab for vmpressure is it's not fair with
>>> LRU pages. LRU pages are 1:1 cost model for scan:free but slab shriking
>>> depends the each slab's object population. It means it's impossible to
>>> get stable cost model with current slab shrinkg model, unfortunately.
>>> So I don't obejct this patch although I want to see slab shrink model's
>>> change which is heavy-handed work.
>>>
>> Looking at the code, the slab reclaimed pages started getting passed to
>> vmpressure after the commit ("mm: vmscan: invoke slab shrinkers from
>> shrink_zone()").
>> But as you said, this may be helpful for slab intensive workloads. But in its
>> current form I think it results in incorrect vmpressure reporting because of not
>> accounting the slab scanned pages. Resending the patch with a modified
>> commit msg
>> since the underflow issue is fixed separately. Thanks Minchan.
> Make sense.
>
> Thanks, Vinayak!
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
> .
>

[toc] | [next] | [standalone]

#1659346

On 2017/6/7 10:53, Minchan Kim wrote:
> Hi,
>
> On Tue, Jun 06, 2017 at 09:00:55PM +0800, zhong jiang wrote:
>> On 2017/1/31 7:40, Minchan Kim wrote:
>>> Hi Vinayak,
>>> Sorry for late response. It was Lunar New Year holidays.
>>>
>>> On Fri, Jan 27, 2017 at 01:43:23PM +0530, vinayak menon wrote:
>>>>> Thanks for the explain. However, such case can happen with THP page
>>>>> as well as slab. In case of THP page, nr_scanned is 1 but nr_reclaimed
>>>>> could be 512 so I think vmpressure should have a logic to prevent undeflow
>>>>> regardless of slab shrinking.
>>>>>
>>>> I see. Going to send a vmpressure fix. But, wouldn't the THP case
>>>> result in incorrect
>>>> vmpressure reporting even if we fix the vmpressure underflow problem ?
>>> If a THP page is reclaimed, it reports lower pressure due to bigger
>>> reclaim ratio(ie, reclaimed/scanned) compared to normal pages but
>>> it's not a problem, is it? Because VM reclaimed more memory than
>>> expected so memory pressure isn't severe now.
>>   Hi, Minchan
>>
>>   THP lru page is reclaimed, reclaim ratio bigger make sense. but I read the code, I found
>>   THP is split to normal pages and loop again.  reclaimed pages should not be bigger
>>    than nr_scan.  because of each loop will increase nr_scan counter.
>>  
>>    It is likely  I miss something.  you can point out the point please.
> You are absolutely right.
>
> I got confused by nr_scanned from isolate_lru_pages and sc->nr_scanned
> from shrink_page_list.
>
> Thanks.
>
>
> .
>
 Hi, Minchan

 I will send the revert patch shortly. how do you think?

 Thanks
 zhongjiang

[toc] | [prev] | [next] | [standalone]

#1659348

Hi,

On Tue, Jun 06, 2017 at 09:00:55PM +0800, zhong jiang wrote:
> On 2017/1/31 7:40, Minchan Kim wrote:
> > Hi Vinayak,
> > Sorry for late response. It was Lunar New Year holidays.
> >
> > On Fri, Jan 27, 2017 at 01:43:23PM +0530, vinayak menon wrote:
> >>> Thanks for the explain. However, such case can happen with THP page
> >>> as well as slab. In case of THP page, nr_scanned is 1 but nr_reclaimed
> >>> could be 512 so I think vmpressure should have a logic to prevent undeflow
> >>> regardless of slab shrinking.
> >>>
> >> I see. Going to send a vmpressure fix. But, wouldn't the THP case
> >> result in incorrect
> >> vmpressure reporting even if we fix the vmpressure underflow problem ?
> > If a THP page is reclaimed, it reports lower pressure due to bigger
> > reclaim ratio(ie, reclaimed/scanned) compared to normal pages but
> > it's not a problem, is it? Because VM reclaimed more memory than
> > expected so memory pressure isn't severe now.
>   Hi, Minchan
> 
>   THP lru page is reclaimed, reclaim ratio bigger make sense. but I read the code, I found
>   THP is split to normal pages and loop again.  reclaimed pages should not be bigger
>    than nr_scan.  because of each loop will increase nr_scan counter.
>  
>    It is likely  I miss something.  you can point out the point please.

You are absolutely right.

I got confused by nr_scanned from isolate_lru_pages and sc->nr_scanned
from shrink_page_list.

Thanks.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web