|
Thanks for you feedback:)
Actually last patch has some problem for calculating lru size when swap is` on.
I modified it as patch 0001 and add another debug patch to show how far refault distance could be.
Actually I was working on some proactive reclaim solution, we'd like to filter out the cold pages and trigger reclaim ahead of memory pressure,
in order to accommodate more free memory for containers scenario. Because, when containers created, they will request a bunch of memory
at a burst. So I want to apportion the overhead of global direct reclaim at the cost of evicting some pages which was cold.
Sincerely, I cannot use a debug version kernel to work in production environment. So I was worrying about whether meaningful data was reclaimed
by my solution. So I have to see the refault rate, but not sure whether refault is accurate for huge size file, for example database file, map
data. That's the background about this patch. Thanks again.
Best Regards,
Yongmei.
发件人: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
发送时间: 2021年9月15日 11:39 收件人: Yongmei Xie <yongmeixie@xxxxxxxxxxx> 抄送: linux-mm@xxxxxxxxx <linux-mm@xxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx <linux-kernel@xxxxxxxxxxxxxxx>; hannes@xxxxxxxxxxx <hannes@xxxxxxxxxxx> 主题: Re: [PATCH] mm/workingset: don't count as refault (file/anon) if refault distance is too long On Sun, 12 Sep 2021 19:54:47 +0800 Yongmei Xie <yongmeixie@xxxxxxxxxxx> wrote:
> The current implementation count all the pages which have shadow entry in radix tree as > the event of refault (page or anon). That means all the pages which have ever been > cached in lru are counted as refault. But I think it's not 100% percent correct. > > Because usually inode has much longer life cycle than the pages belonging to it. > So if the inode was accessed from time to time, then it won't be reclaimed unless much > severe memory pressure happens. > > Then if page was reclaimed several days ago, when it's accessed again, it will be marked as > refault event. Then page was reclaimed an hour ago, when it's accessed again, it will be > marked as refault event as well. From the refault metric alone, I cannot tell whether the > previous reclaim process has evicted some useful pages. That makes things worse in situation > of proactive reclaim. We's like to known whehter the previous policy reclaim too much > meaningful data other than working set transition. So we'd like see the refault rate, but it > includes all the historical reclaim. > > >From my point of view, if the refaut distance is larger than file cache size, we don't > have to count it refault at all. Because it's too long to be memorized down. Thanks. Do you have any runtime testing results which demonstrate a benefit? |
Attachment:
0001-mm-workingset-don-t-count-as-refault-file-anon-if-re.patch
Description: 0001-mm-workingset-don-t-count-as-refault-file-anon-if-re.patch
Attachment:
0002-mm-memcontrol-add-diagram-to-track-refault-distance.patch
Description: 0002-mm-memcontrol-add-diagram-to-track-refault-distance.patch
