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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
