All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Minchan Kim <minchan@kernel.org>
Cc: akpm@linux-foundation.org, ebru.akagunduz@gmail.com,
	aarcange@redhat.com, aneesh.kumar@linux.vnet.ibm.com,
	boaz@plexistor.com, gorcunov@openvz.org, hannes@cmpxchg.org,
	hughd@google.com, iamjoonsoo.kim@lge.com,
	kirill.shutemov@linux.intel.com, mgorman@suse.de,
	n-horiguchi@ah.jp.nec.com, riel@redhat.com, rientjes@google.com,
	vbabka@suse.cz, mm-commits@vger.kernel.org, linux-mm@kvack.org
Subject: Re: + mm-thp-avoid-unnecessary-swapin-in-khugepaged.patch added to -mm tree
Date: Thu, 19 May 2016 09:03:57 +0200	[thread overview]
Message-ID: <20160519070357.GB26110@dhcp22.suse.cz> (raw)
In-Reply-To: <20160519050038.GA16318@bbox>

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@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>

  reply	other threads:[~2016-05-19  7:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-27 21:17 + mm-thp-avoid-unnecessary-swapin-in-khugepaged.patch added to -mm tree akpm
2016-04-28 15:19 ` Michal Hocko
2016-05-17  7:58   ` Michal Hocko
2016-05-17  9:02     ` Michal Hocko
2016-05-17 11:31       ` Kirill A. Shutemov
2016-05-17 12:25         ` Michal Hocko
2016-05-19  5:00       ` Minchan Kim
2016-05-19  7:03         ` Michal Hocko [this message]
2016-05-19  7:27           ` Minchan Kim
2016-05-19  7:39             ` Michal Hocko
2016-05-20  0:21               ` Minchan Kim
2016-05-20  6:39                 ` Michal Hocko
2016-05-20  7:26                   ` Minchan Kim
2016-05-20  7:34                     ` Michal Hocko
2016-05-20  7:44                       ` Minchan Kim
2016-05-20  8:02                         ` Michal Hocko
2016-05-20  8:26                           ` Minchan Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160519070357.GB26110@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=boaz@plexistor.com \
    --cc=ebru.akagunduz@gmail.com \
    --cc=gorcunov@openvz.org \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=minchan@kernel.org \
    --cc=mm-commits@vger.kernel.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.