On Thu 19-05-16 14:00:38, Minchan Kim wrote: > On Tue, May 17, 2016 at 11:02:54AM +0200, Michal Hocko wrote: > > On Tue 17-05-16 09:58:15, Michal Hocko wrote: > > > On Thu 28-04-16 17:19:21, Michal Hocko wrote: > > > > On Wed 27-04-16 14:17:20, Andrew Morton wrote: > > > > [...] > > > > > @@ -2484,7 +2485,14 @@ static void collapse_huge_page(struct mm > > > > > goto out; > > > > > } > > > > > > > > > > - __collapse_huge_page_swapin(mm, vma, address, pmd); > > > > > + swap = get_mm_counter(mm, MM_SWAPENTS); > > > > > + curr_allocstall = sum_vm_event(ALLOCSTALL); > > > > > + /* > > > > > + * When system under pressure, don't swapin readahead. > > > > > + * So that avoid unnecessary resource consuming. > > > > > + */ > > > > > + if (allocstall == curr_allocstall && swap != 0) > > > > > + __collapse_huge_page_swapin(mm, vma, address, pmd); > > > > > > > > > > anon_vma_lock_write(vma->anon_vma); > > > > > > > > > > > > > I have mentioned that before already but this seems like a rather weak > > > > heuristic. Don't we really rather teach __collapse_huge_page_swapin > > > > (resp. do_swap_page) do to an optimistic GFP_NOWAIT allocations and > > > > back off under the memory pressure? > > > > > > I gave it a try and it doesn't seem really bad. Untested and I might > > > have missed something really obvious but what do you think about this > > > approach rather than relying on ALLOCSTALL which is really weak > > > heuristic: > > I like this approach rather than playing with allocstall diff of vmevent > which can be disabled in some configuration and it's not a good indicator > to represent current memory pressure situation. Not only that it won't work for e.g. memcg configurations because we would end up reclaiming that memcg as the gfp mask tells us to do so and ALLOCSTALL would be quite about that. > However, I agree with Rik's requirement which doesn't want to turn over > page cache for collapsing THP page via swapin. So, your suggestion cannot > prevent it because khugepaged can consume memory through this swapin > operation continuously while kswapd is doing aging of LRU list in parallel. > IOW, fluctuation between HIGH and LOW watermark. I am not sure this is actually a problem. We have other sources of opportunistic allocations with some fallback and those wake up kswapd (they only clear __GFP_DIRECT_RECLAIM). Also this swapin should happen only when a certain portion of the huge page is already populated so it won't happen all the time and sounds like we would benefit from the reclaimed page cache in favor of the THP. > So, How about using waitqueue_active(&pgdat->kswapd_wait) to detect > current memory pressure? So if kswapd is active, we could avoid swapin > for THP collapsing. Dunno, this sounds quite arbitrary. And I am even not sure this all optimistic swap in is a huge win to be honest. I just really hate the ALLOCSTALL heuristic because it simply doesn't work. -- Michal Hocko SUSE Labs -- 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>