All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Lisa Du <cldu@marvell.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Bob Liu <lliubbo@gmail.com>
Subject: Re: Possible deadloop in direct reclaim?
Date: Fri, 2 Aug 2013 12:53:33 +0900	[thread overview]
Message-ID: <20130802035333.GD32486@bbox> (raw)
In-Reply-To: <89813612683626448B837EE5A0B6A7CB3B630BE43E@SC-VEXCH4.marvell.com>

On Thu, Aug 01, 2013 at 08:17:56PM -0700, Lisa Du wrote:
> >-----Original Message-----
> >From: Minchan Kim [mailto:minchan@kernel.org]
> >Sent: 2013a1'8ae??2ae?JPY 10:26
> >To: Lisa Du
> >Cc: linux-mm@kvack.org; KOSAKI Motohiro
> >Subject: Re: Possible deadloop in direct reclaim?
> >
> >Hello Lisa and KOSAKI,
> >
> >Lisa's quote style is very hard to follow so I'd like to write at bottom
> >as ignoring line by line rule.
> >
> >Lisa, please correct your MUA.
> I'm really sorry for my quote style, will improve it in my following mails.
> >
> >
> >I reviewed current mmotm because recently Mel changed kswapd a lot and
> >all_unreclaimable patch history today.
> >What I see is recent mmotm has a same problem, too if system have no swap
> >and no compaction. Of course, compaction is default yes option so we could
> >recommend to enable if system works well but it's up to user and we should
> >avoid direct reclaim hang although user disable compaction.
> >
> >When I see the patch history, real culprit is 929bea7c.
> >
> >"  zone->all_unreclaimable and zone->pages_scanned are neigher atomic
> >    variables nor protected by lock.  Therefore zones can become a state of
> >    zone->page_scanned=0 and zone->all_unreclaimable=1.  In this case, current
> >    all_unreclaimable() return false even though zone->all_unreclaimabe=1."
> >
> >I understand the problem but apparently, it makes Lisa's problem because
> >kswapd can give up balancing when high order allocation happens to prevent
> >excessive reclaim with assuming the process requested high order allocation
> >can do direct reclaim/compaction. But what if the process can't reclaim
> >by no swap but lots of anon pages and can't compact by !CONFIG_COMPACTION?
> >
> >In such system, OOM kill is natural but not hang.
> >So, a solution we can fix simply introduces zone_reclaimable check again in
> >all_unreclaimabe() like this.
> >
> >What do you think about it?
> >
> >It's a same patch Lisa posted so we should give a credit
> >to her/him(Sorry I'm not sure) if we agree thie approach.
> >
> >Lisa, If KOSAKI agree with this, could you resend this patch with your SOB?
> >
> >Thanks.
> >
> >diff --git a/mm/vmscan.c b/mm/vmscan.c
> >index a3bf7fd..78f46d8 100644
> >--- a/mm/vmscan.c
> >+++ b/mm/vmscan.c
> >@@ -2367,7 +2367,15 @@ static bool all_unreclaimable(struct zonelist *zonelist,
> > 			continue;
> > 		if (!cpuset_zone_allowed_hardwall(zone, GFP_KERNEL))
> > 			continue;
> >-		if (!zone->all_unreclaimable)
> >+		/*
> >+		 * zone->page_scanned and could be raced so we need
> >+		 * dobule check by zone->all_unreclaimable. Morever, kswapd
> >+		 * could skip (zone->all_unreclaimable = 1) if the zone
> >+		 * is heavily fragmented but enough free pages to meet
> >+		 * high watermark. In such case, kswapd never set
> >+		 * all_unreclaimable to 1 so we need zone_reclaimable, too.
> >+		 */
> >+		if (!zone->all_unreclaimable || zone_reclaimable(zone))
> > 			return false;
> > 	}
>    I'm afraid this patch may can't help.
>    zone->all_unreclaimable = 0 will always result the false return,
>    zone_reclaimable(zone) check wouldn't take effect no matter
>    it's true of false right?

You're right. It was not what I want but check both conditions.

> 
> Also Bob found below thread, seems Kosaki also found same issue:
> mm, vmscan: fix do_try_to_free_pages() livelock
> https://lkml.org/lkml/2012/6/14/74

I remember it and AFAIRC, I had a concern because description was
too vague without detailed example and I fixed Aaditya's problem with
another approach. That's why it wasn't merged at that time.

Now, we have a real problem and analysis so I think KOSAKI's patch makes
perfect to me.

Lisa, Could you resend KOSAKI's patch with more detailed description?

> 
> >
> >
> >
> >--
> >Kind regards,
> >Minchan Kim

-- 
Kind regards,
Minchan Kim

--
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:[~2013-08-02  3:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-23  4:58 Possible deadloop in direct reclaim? Lisa Du
2013-07-23 20:28 ` Christoph Lameter
2013-07-24  1:21   ` Lisa Du
2013-07-25 18:19     ` KOSAKI Motohiro
2013-07-26  1:11       ` Lisa Du
2013-07-29 16:44         ` KOSAKI Motohiro
2013-07-30  1:27           ` Lisa Du
2013-08-01  2:24           ` Lisa Du
2013-08-01  2:45             ` KOSAKI Motohiro
2013-08-01  4:21               ` Bob Liu
2013-08-03 21:22                 ` KOSAKI Motohiro
2013-08-04 23:50                   ` Minchan Kim
2013-08-01  5:19               ` Lisa Du
2013-08-01  8:56                 ` Russell King - ARM Linux
2013-08-02  1:18                   ` Lisa Du
2013-07-29  1:32       ` Lisa Du
2013-07-24  1:18 ` Bob Liu
2013-07-24  1:31   ` Lisa Du
2013-07-24  2:23   ` Lisa Du
2013-07-24  3:38     ` Bob Liu
2013-07-24  5:58       ` Lisa Du
2013-07-25 18:14   ` KOSAKI Motohiro
2013-07-26  1:22     ` Bob Liu
2013-07-29 16:46       ` KOSAKI Motohiro
2013-08-01  5:43 ` Minchan Kim
2013-08-01  6:13   ` Lisa Du
2013-08-01  7:33     ` Minchan Kim
2013-08-01  8:20       ` Lisa Du
2013-08-01  8:42         ` Minchan Kim
2013-08-02  1:03           ` Lisa Du
2013-08-02  2:26           ` Minchan Kim
2013-08-02  2:33             ` Minchan Kim
2013-08-02  3:17             ` Lisa Du
2013-08-02  3:53               ` Minchan Kim [this message]
2013-08-02  8:08                 ` Lisa Du
2013-08-04 23:47                   ` 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=20130802035333.GD32486@bbox \
    --to=minchan@kernel.org \
    --cc=cldu@marvell.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=lliubbo@gmail.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.