From: Wu Fengguang <fengguang.wu@intel.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mel@linux.vnet.ibm.com>,
Dave Young <hidave.darkstar@gmail.com>,
linux-mm <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Christoph Lameter <cl@linux.com>,
Dave Chinner <david@fromorbit.com>,
David Rientjes <rientjes@google.com>
Subject: Re: [RFC][PATCH] mm: cut down __GFP_NORETRY page allocation failures
Date: Mon, 2 May 2011 21:49:54 +0800 [thread overview]
Message-ID: <20110502134953.GA12281@localhost> (raw)
In-Reply-To: <20110502132958.GA9690@localhost>
On Mon, May 02, 2011 at 09:29:58PM +0800, Wu Fengguang wrote:
> > > + if (preferred_zone &&
> > > + zone_watermark_ok_safe(preferred_zone, sc->order,
> > > + high_wmark_pages(preferred_zone),
> > > + zone_idx(preferred_zone), 0))
> > > + goto out;
> > > + }
> >
> > As I said, I think direct reclaim path sould be fast if possbile and
> > it should not a function of min_free_kbytes.
>
> It can be made not a function of min_free_kbytes by simply changing
> high_wmark_pages() to low_wmark_pages() in the above chunk, since
> direct reclaim is triggered when ALLOC_WMARK_LOW cannot be satisfied,
> ie. it just dropped below low_wmark_pages().
>
> But still, it costs 62ms reclaim latency (base kernel is 29ms).
I got new findings: the CPU schedule delays are much larger than
reclaim delays. It does make the "direct reclaim until low watermark
OK" latency less a problem :)
1000 dd test case:
RECLAIM delay CPU delay nr_alloc_fail CAL (last CPU)
base kernel 29ms 244ms 14586 218440
patched 62ms 215ms 5004 325
Thanks,
Fengguang
WARNING: multiple messages have this Message-ID (diff)
From: Wu Fengguang <fengguang.wu@intel.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mel@linux.vnet.ibm.com>,
Dave Young <hidave.darkstar@gmail.com>,
linux-mm <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Christoph Lameter <cl@linux.com>,
Dave Chinner <david@fromorbit.com>,
David Rientjes <rientjes@google.com>
Subject: Re: [RFC][PATCH] mm: cut down __GFP_NORETRY page allocation failures
Date: Mon, 2 May 2011 21:49:54 +0800 [thread overview]
Message-ID: <20110502134953.GA12281@localhost> (raw)
In-Reply-To: <20110502132958.GA9690@localhost>
On Mon, May 02, 2011 at 09:29:58PM +0800, Wu Fengguang wrote:
> > > + if (preferred_zone &&
> > > + zone_watermark_ok_safe(preferred_zone, sc->order,
> > > + high_wmark_pages(preferred_zone),
> > > + zone_idx(preferred_zone), 0))
> > > + goto out;
> > > + }
> >
> > As I said, I think direct reclaim path sould be fast if possbile and
> > it should not a function of min_free_kbytes.
>
> It can be made not a function of min_free_kbytes by simply changing
> high_wmark_pages() to low_wmark_pages() in the above chunk, since
> direct reclaim is triggered when ALLOC_WMARK_LOW cannot be satisfied,
> ie. it just dropped below low_wmark_pages().
>
> But still, it costs 62ms reclaim latency (base kernel is 29ms).
I got new findings: the CPU schedule delays are much larger than
reclaim delays. It does make the "direct reclaim until low watermark
OK" latency less a problem :)
1000 dd test case:
RECLAIM delay CPU delay nr_alloc_fail CAL (last CPU)
base kernel 29ms 244ms 14586 218440
patched 62ms 215ms 5004 325
Thanks,
Fengguang
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-05-02 13:50 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-26 5:49 readahead and oom Dave Young
2011-04-26 5:49 ` Dave Young
2011-04-26 5:55 ` Wu Fengguang
2011-04-26 5:55 ` Wu Fengguang
2011-04-26 6:05 ` Dave Young
2011-04-26 6:05 ` Dave Young
2011-04-26 6:07 ` Dave Young
2011-04-26 6:07 ` Dave Young
2011-04-26 6:25 ` Wu Fengguang
2011-04-26 6:25 ` Wu Fengguang
2011-04-26 6:29 ` Dave Young
2011-04-26 6:29 ` Dave Young
2011-04-26 6:34 ` Wu Fengguang
2011-04-26 6:34 ` Wu Fengguang
2011-04-26 6:50 ` KOSAKI Motohiro
2011-04-26 6:50 ` KOSAKI Motohiro
2011-04-26 7:41 ` Minchan Kim
2011-04-26 7:41 ` Minchan Kim
2011-04-26 9:20 ` Wu Fengguang
2011-04-26 9:20 ` Wu Fengguang
2011-04-26 9:28 ` Minchan Kim
2011-04-26 9:28 ` Minchan Kim
2011-04-26 10:18 ` Pekka Enberg
2011-04-26 10:18 ` Pekka Enberg
2011-04-26 19:47 ` Andrew Morton
2011-04-26 19:47 ` Andrew Morton
2011-04-28 4:19 ` Wu Fengguang
2011-04-28 13:36 ` [RFC][PATCH] mm: cut down __GFP_NORETRY page allocation failures Wu Fengguang
2011-04-28 13:36 ` Wu Fengguang
2011-04-28 13:38 ` [patch] vmstat: account " Wu Fengguang
2011-04-28 13:38 ` Wu Fengguang
2011-04-28 13:50 ` KOSAKI Motohiro
2011-04-28 13:50 ` KOSAKI Motohiro
2011-04-29 2:28 ` [RFC][PATCH] mm: cut down __GFP_NORETRY " Wu Fengguang
2011-04-29 2:28 ` Wu Fengguang
2011-04-29 2:58 ` Wu Fengguang
2011-04-29 2:58 ` Wu Fengguang
2011-04-30 14:17 ` Wu Fengguang
2011-04-30 14:17 ` Wu Fengguang
2011-05-01 16:35 ` Minchan Kim
2011-05-01 16:35 ` Minchan Kim
2011-05-01 16:37 ` Minchan Kim
2011-05-01 16:37 ` Minchan Kim
2011-05-02 10:14 ` KOSAKI Motohiro
2011-05-02 10:14 ` KOSAKI Motohiro
2011-05-03 0:53 ` Minchan Kim
2011-05-03 0:53 ` Minchan Kim
2011-05-03 1:25 ` KOSAKI Motohiro
2011-05-03 1:25 ` KOSAKI Motohiro
2011-05-02 10:29 ` Wu Fengguang
2011-05-02 11:08 ` Wu Fengguang
2011-05-02 11:08 ` Wu Fengguang
2011-05-03 0:49 ` Minchan Kim
2011-05-03 0:49 ` Minchan Kim
2011-05-03 3:51 ` Wu Fengguang
2011-05-03 3:51 ` Wu Fengguang
2011-05-03 4:17 ` Minchan Kim
2011-05-03 4:17 ` Minchan Kim
2011-05-02 13:29 ` Wu Fengguang
2011-05-02 13:29 ` Wu Fengguang
2011-05-02 13:49 ` Wu Fengguang [this message]
2011-05-02 13:49 ` Wu Fengguang
2011-05-03 0:27 ` Satoru Moriya
2011-05-03 0:27 ` Satoru Moriya
2011-05-03 2:49 ` Wu Fengguang
2011-05-03 2:49 ` Wu Fengguang
2011-05-04 1:56 ` Dave Young
2011-05-04 1:56 ` Dave Young
2011-05-04 2:32 ` Dave Young
2011-05-04 2:32 ` Dave Young
2011-05-04 2:56 ` Wu Fengguang
2011-05-04 2:56 ` Wu Fengguang
2011-05-04 4:23 ` Wu Fengguang
2011-05-04 4:23 ` Wu Fengguang
2011-05-04 4:00 ` Wu Fengguang
2011-05-04 4:00 ` Wu Fengguang
2011-05-04 7:33 ` Dave Young
2011-05-04 7:33 ` Dave Young
2011-04-26 6:13 ` readahead and oom Wu Fengguang
2011-04-26 6:13 ` Wu Fengguang
2011-04-26 6:23 ` Dave Young
2011-04-26 6:23 ` Dave Young
2011-04-26 9:37 ` [PATCH] mm: readahead page allocations are OK to fail Wu Fengguang
2011-04-26 9:37 ` Wu Fengguang
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=20110502134953.GA12281@localhost \
--to=fengguang.wu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=david@fromorbit.com \
--cc=hidave.darkstar@gmail.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@linux.vnet.ibm.com \
--cc=minchan.kim@gmail.com \
--cc=rientjes@google.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.