On Tue, Jul 17, 2018 at 7:23 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Tue 17-07-18 07:13:52, Daniel Drake wrote: >> On Tue, Jul 17, 2018 at 6:25 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: >> > Yes this is really unfortunate. One thing that could help would be to >> > consider a trashing level during the reclaim (get_scan_count) to simply >> > forget about LRUs which are constantly refaulting pages back. We already >> > have the infrastructure for that. We just need to plumb it in. >> >> Can you go into a bit more detail about that infrastructure and how we >> might detect which pages are being constantly refaulted? I'm >> interested in spending a few hours on this topic to see if I can come >> up with anything. > > mm/workingset.c allows for tracking when an actual page got evicted. > workingset_refault tells us whether a give filemap fault is a recent > refault and activates the page if that is the case. So what you need is > to note how many refaulted pages we have on the active LRU list. If that > is a large part of the list and if the inactive list is really small > then we know we are trashing. Thanks for the guidance. So this sounds like it is something that should be done on a timer (or on some other condition?), check the state of the active LRU list as described and if things are bad then invoke the OOM killer? I'm having trouble linking that idea to your original suggestion: > One thing that could help would be to consider a trashing level during the reclaim > (get_scan_count) to simply forget about LRUs which are constantly refaulting > pages back. which I interpret to mean that the for_each_evictable_lru loop in get_scan_count should skip over constantly-refaulty LRUs rather than add them to nr[] and lru_pages, which I assume would then cause direct reclaim to fail when we are thrashing, leading to OOM kill? Are these two different ideas, or am I just misunderstanding something basic? That confusion aside, studying the code to understand how I can determine if a page is being constantly refaulted or not, I see that the well documented condition for this (in workingset_refault) is: (refault - eviction) & EVICTION_MASK <= active_file refault and active_file are just values from the lruvec which seems easily accessible. However the eviction value is taken at the point of page eviction, and it is then stored in the shadow entries stored in the page cache for pages that have been evicted, but the shadow entry is then lost when the page is reactivated. The suggestion(s) seem to revolve around checking if currently-active pages are refaulting a lot, and I am still not clear on how to determine that, given that the shadow/eviction information was lost at the point when those active pages were refaulted. BTW feel free to drop this thread if you are busy, or delay your response to a convenient time. I'm new to this area and probably making silly mistakes, and not yet convinced that I'll be able to see it through. Daniel -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
