All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Michal Hocko <mhocko@kernel.org>,
	Vladimir Davydov <vdavydov@virtuozzo.com>
Subject: Re: [RFC] mm: bail out in shrin_inactive_list
Date: Tue, 26 Jul 2016 10:21:57 +0900	[thread overview]
Message-ID: <20160726012157.GA11651@bbox> (raw)
In-Reply-To: <20160725092909.GV11400@suse.de>

On Mon, Jul 25, 2016 at 10:29:09AM +0100, Mel Gorman wrote:
> There is a typo in the subject line.
> 
> On Mon, Jul 25, 2016 at 04:51:59PM +0900, Minchan Kim wrote:
> > With node-lru, if there are enough reclaimable pages in highmem
> > but nothing in lowmem, VM can try to shrink inactive list although
> > the requested zone is lowmem.
> > 
> > The problem is direct reclaimer scans inactive list is fulled with
> 
> 
> > highmem pages to find a victim page at a reqested zone or lower zones
> > but the result is that VM should skip all of pages. 
> 
> Rephease -- The problem is that if the inactive list is full of highmem
> pages then a direct reclaimer searching for a lowmem page waste CPU
> scanning uselessly.

It's better. Thanks.

> 
> > CPU. Even, many direct reclaimers are stalled by too_many_isolated
> > if lots of parallel reclaimer are going on although there are no
> > reclaimable memory in inactive list.
> > 
> > I tried the experiment 4 times in 32bit 2G 8 CPU KVM machine
> > to get elapsed time.
> > 
> > 	hackbench 500 process 2
> > 
> > = Old =
> > 
> > 1st: 289s 2nd: 310s 3rd: 112s 4th: 272s
> > 
> > = Now =
> > 
> > 1st: 31s  2nd: 132s 3rd: 162s 4th: 50s.
> > 
> > Signed-off-by: Minchan Kim <minchan@kernel.org>
> > ---
> > I believe proper fix is to modify get_scan_count. IOW, I think
> > we should introduce lruvec_reclaimable_lru_size with proper
> > classzone_idx but I don't know how we can fix it with memcg
> > which doesn't have zone stat now. should introduce zone stat
> > back to memcg? Or, it's okay to ignore memcg?
> > 
> 
> I think it's ok to ignore memcg in this case as a memcg shrink is often
> going to be for pages that can use highmem anyway.

So, you mean it's okay to ignore kmemcg case?
If memcg guys agree it, I want to make get_scan_count consider
reclaimable lru size under the reclaim constraint, instead.

> 
> >  mm/vmscan.c | 28 ++++++++++++++++++++++++++++
> >  1 file changed, 28 insertions(+)
> > 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index e5af357..3d285cc 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -1652,6 +1652,31 @@ static int current_may_throttle(void)
> >  		bdi_write_congested(current->backing_dev_info);
> >  }
> >  
> > +static inline bool inactive_reclaimable_pages(struct lruvec *lruvec,
> > +				struct scan_control *sc,
> > +				enum lru_list lru)
> 
> inline is unnecessary. The function is long but only has one caller so
> it'll be inlined automatically.
> 
> > +{
> > +	int zid;
> > +	struct zone *zone;
> > +	bool file = is_file_lru(lru);
> 
> It's more appropriate to use int for file in this case as it's used as a
> multiplier. It'll work either way.
> 
> Otherwise;
> 
> Acked-by: Mel Gorman <mgorman@techsingularity.net>
> 
> -- 
> Mel Gorman
> 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>

WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>, Michal Hocko <mhocko@kernel.org>,
	Vladimir Davydov <vdavydov@virtuozzo.com>
Subject: Re: [RFC] mm: bail out in shrin_inactive_list
Date: Tue, 26 Jul 2016 10:21:57 +0900	[thread overview]
Message-ID: <20160726012157.GA11651@bbox> (raw)
In-Reply-To: <20160725092909.GV11400@suse.de>

On Mon, Jul 25, 2016 at 10:29:09AM +0100, Mel Gorman wrote:
> There is a typo in the subject line.
> 
> On Mon, Jul 25, 2016 at 04:51:59PM +0900, Minchan Kim wrote:
> > With node-lru, if there are enough reclaimable pages in highmem
> > but nothing in lowmem, VM can try to shrink inactive list although
> > the requested zone is lowmem.
> > 
> > The problem is direct reclaimer scans inactive list is fulled with
> 
> 
> > highmem pages to find a victim page at a reqested zone or lower zones
> > but the result is that VM should skip all of pages. 
> 
> Rephease -- The problem is that if the inactive list is full of highmem
> pages then a direct reclaimer searching for a lowmem page waste CPU
> scanning uselessly.

It's better. Thanks.

> 
> > CPU. Even, many direct reclaimers are stalled by too_many_isolated
> > if lots of parallel reclaimer are going on although there are no
> > reclaimable memory in inactive list.
> > 
> > I tried the experiment 4 times in 32bit 2G 8 CPU KVM machine
> > to get elapsed time.
> > 
> > 	hackbench 500 process 2
> > 
> > = Old =
> > 
> > 1st: 289s 2nd: 310s 3rd: 112s 4th: 272s
> > 
> > = Now =
> > 
> > 1st: 31s  2nd: 132s 3rd: 162s 4th: 50s.
> > 
> > Signed-off-by: Minchan Kim <minchan@kernel.org>
> > ---
> > I believe proper fix is to modify get_scan_count. IOW, I think
> > we should introduce lruvec_reclaimable_lru_size with proper
> > classzone_idx but I don't know how we can fix it with memcg
> > which doesn't have zone stat now. should introduce zone stat
> > back to memcg? Or, it's okay to ignore memcg?
> > 
> 
> I think it's ok to ignore memcg in this case as a memcg shrink is often
> going to be for pages that can use highmem anyway.

So, you mean it's okay to ignore kmemcg case?
If memcg guys agree it, I want to make get_scan_count consider
reclaimable lru size under the reclaim constraint, instead.

> 
> >  mm/vmscan.c | 28 ++++++++++++++++++++++++++++
> >  1 file changed, 28 insertions(+)
> > 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index e5af357..3d285cc 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -1652,6 +1652,31 @@ static int current_may_throttle(void)
> >  		bdi_write_congested(current->backing_dev_info);
> >  }
> >  
> > +static inline bool inactive_reclaimable_pages(struct lruvec *lruvec,
> > +				struct scan_control *sc,
> > +				enum lru_list lru)
> 
> inline is unnecessary. The function is long but only has one caller so
> it'll be inlined automatically.
> 
> > +{
> > +	int zid;
> > +	struct zone *zone;
> > +	bool file = is_file_lru(lru);
> 
> It's more appropriate to use int for file in this case as it's used as a
> multiplier. It'll work either way.
> 
> Otherwise;
> 
> Acked-by: Mel Gorman <mgorman@techsingularity.net>
> 
> -- 
> Mel Gorman
> SUSE Labs

  reply	other threads:[~2016-07-26  1:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-25  7:51 [RFC] mm: bail out in shrin_inactive_list Minchan Kim
2016-07-25  7:51 ` Minchan Kim
2016-07-25  9:29 ` Mel Gorman
2016-07-25  9:29   ` Mel Gorman
2016-07-26  1:21   ` Minchan Kim [this message]
2016-07-26  1:21     ` Minchan Kim
2016-07-26  7:46     ` Mel Gorman
2016-07-26  7:46       ` Mel Gorman
2016-07-26  8:27       ` Minchan Kim
2016-07-26  8:27         ` Minchan Kim
2016-07-29 14:11 ` Johannes Weiner
2016-07-29 14:11   ` Johannes Weiner
2016-08-01 23:46   ` Minchan Kim
2016-08-01 23:46     ` 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=20160726012157.GA11651@bbox \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=vdavydov@virtuozzo.com \
    /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.