From: Mel Gorman <mel@csn.ul.ie>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>,
Frans Pop <elendil@planet.nl>, Jiri Kosina <jkosina@suse.cz>,
Sven Geggus <lists@fuchsschwanzdomain.de>,
Karol Lewandowski <karol.k.lewandowski@gmail.com>,
Tobias Oetiker <tobi@oetiker.ch>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
David Miller <davem@davemloft.net>,
Reinette Chatre <reinette.chatre@intel.com>,
Kalle Valo <kalle.valo@iki.fi>,
Mohamed Abbas <mohamed.abbas@intel.com>,
Jens Axboe <jens.axboe@oracle.com>,
"John W. Linville" <linville@tuxdriver.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
Greg Kroah-Hartman <gregkh@suse.de>,
Stephan von Krawczynski <skraw@ithnet.com>,
Kernel Testers List <kernel-testers@vger.kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed
Date: Tue, 27 Oct 2009 12:27:07 +0000 [thread overview]
Message-ID: <20091027122707.GD8900@csn.ul.ie> (raw)
In-Reply-To: <20091026222159.2F72.A69D9226@jp.fujitsu.com>
On Tue, Oct 27, 2009 at 11:42:55AM +0900, KOSAKI Motohiro wrote:
> > On Mon, 26 Oct 2009, KOSAKI Motohiro wrote:
> >
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index bf72055..5a27896 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -1899,6 +1899,12 @@ rebalance:
> > > if (should_alloc_retry(gfp_mask, order, pages_reclaimed)) {
> > > /* Wait for some write requests to complete then retry */
> > > congestion_wait(BLK_RW_ASYNC, HZ/50);
> > > +
> > > + /*
> > > + * While we wait congestion wait, Amount of free memory can
> > > + * be changed dramatically. Thus, we kick kswapd again.
> > > + */
> > > + wake_all_kswapd(order, zonelist, high_zoneidx);
> > > goto rebalance;
> > > }
> > >
> >
> > We're blocking to finish writeback of the directly reclaimed memory, why
> > do we need to wake kswapd afterwards?
>
> the same reason of "goto restart" case. that's my intention.
> if following scenario occur, it is equivalent that we didn't call wake_all_kswapd().
>
> 1. call congestion_wait()
> 2. kswapd reclaimed lots memory and sleep
> 3. another task consume lots memory
> 4. wakeup from congestion_wait()
>
> IOW, if we falled into __alloc_pages_slowpath(), we naturally expect
> next page_alloc() don't fall into slowpath. however if kswapd end to
> its work too early, this assumption isn't true.
>
> Is this too pessimistic assumption?
>
hmm.
The reason it's not woken in both cases a second time was to match the
behaviour of 2.6.30. If the direct reclaimer goes asleep and another task
consumes the memory the direct reclaimer freed then the greedy process should
kick kswapd back awake again as free memory goes below the low watermark.
However, if the greedy process was allocating order-0, it's possible that
the watermarks for order-0 are being met leaving kswapd alone where as the
high-order ones are not leaving kswapd to go back asleep or to reclaim at
the wrong order.
It's a functional change but I can add it to the list of things to
consider. Thanks
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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>
next prev parent reply other threads:[~2009-10-27 12:27 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-22 14:22 [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 Mel Gorman
2009-10-22 14:22 ` [PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed Mel Gorman
2009-10-22 14:24 ` [PATCH 1/5 Against 2.6.31.4] " Mel Gorman
2009-10-22 14:41 ` [PATCH 1/5] " Pekka Enberg
2009-10-22 15:49 ` Mel Gorman
2009-10-26 1:11 ` KOSAKI Motohiro
2009-10-26 7:10 ` David Rientjes
2009-10-27 2:42 ` KOSAKI Motohiro
2009-10-27 12:27 ` Mel Gorman [this message]
2009-10-22 14:22 ` [PATCH 2/5] page allocator: Do not allow interrupts to use ALLOC_HARDER Mel Gorman
2009-10-22 16:33 ` Stephan von Krawczynski
2009-10-22 16:37 ` Mel Gorman
2009-10-23 9:57 ` Stephan von Krawczynski
2009-10-24 2:03 ` Christoph Lameter
2009-10-27 15:19 ` Mel Gorman
2009-10-25 12:57 ` Stephan von Krawczynski
2009-10-26 1:15 ` KOSAKI Motohiro
2009-10-22 14:22 ` [PATCH 3/5] vmscan: Force kswapd to take notice faster when high-order watermarks are being hit Mel Gorman
2009-10-23 17:52 ` Vincent Li
2009-10-23 22:12 ` Vincent Li
2009-10-27 10:38 ` Mel Gorman
2009-10-27 2:42 ` KOSAKI Motohiro
2009-10-22 14:22 ` [PATCH 4/5] page allocator: Pre-emptively wake kswapd when high-order watermarks are hit Mel Gorman
2009-10-22 19:41 ` David Rientjes
2009-10-23 9:13 ` Mel Gorman
2009-10-23 9:36 ` David Rientjes
2009-10-23 11:25 ` Mel Gorman
2009-10-23 11:31 ` Tobias Oetiker
2009-10-23 13:39 ` Mel Gorman
2009-10-27 2:42 ` KOSAKI Motohiro
2009-10-27 15:26 ` Mel Gorman
2009-10-22 14:22 ` [PATCH 5/5] ONLY-APPLY-IF-STILL-FAILING Revert 373c0a7e, 8aa7e847: Fix congestion_wait() sync/async vs read/write confusion Mel Gorman
2009-10-22 14:25 ` Against 2.6.31.4 [PATCH 5/5] " Mel Gorman
2009-10-22 21:49 ` [PATCH 5/5] ONLY-APPLY-IF-STILL-FAILING " Jens Axboe
2009-10-27 2:42 ` KOSAKI Motohiro
2009-10-27 10:29 ` Frans Pop
2009-10-22 14:47 ` [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 Pekka Enberg
2009-10-22 16:03 ` Mel Gorman
2009-10-24 1:52 ` Christoph Lameter
2009-10-24 6:48 ` Pekka Enberg
2009-10-24 6:48 ` Pekka Enberg
2009-10-22 15:43 ` reinette chatre
2009-10-27 10:40 ` Mel Gorman
2009-10-27 23:34 ` reinette chatre
2009-10-23 7:31 ` Sven Geggus
2009-10-23 16:58 ` Karol Lewandowski
2009-10-23 21:12 ` Karol Lewandowski
2009-10-24 13:46 ` Mel LKML
2009-10-28 11:42 ` Karol Lewandowski
2009-10-28 11:59 ` Mel Gorman
2009-10-30 14:23 ` Karol Lewandowski
2009-11-02 20:30 ` Mel Gorman
2009-11-04 2:03 ` Karol Lewandowski
2009-10-28 12:55 ` Tobi Oetiker
2009-10-24 13:51 ` Frans Pop
2009-10-24 14:02 ` Sven Geggus
2009-10-27 13:27 ` Mel Gorman
2009-10-26 17:37 ` Tobias Oetiker
2009-10-27 15:36 ` Mel Gorman
2009-10-26 22:17 ` Frans Pop
2009-10-26 23:45 ` Frans Pop
2009-11-06 6:03 ` Tobias Diedrich
2009-11-06 9:24 ` Mel Gorman
2009-11-06 11:15 ` Tobias Diedrich
2009-11-06 9:24 ` Mel Gorman
2009-11-12 19:30 [PATCH 0/7] Reduce GFP_ATOMIC allocation failures, candidate fix V3 Mel Gorman
2009-11-12 19:30 ` [PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed Mel Gorman
2009-11-12 19:30 [PATCH 0/5] Reduce GFP_ATOMIC allocation failures, candidate fix V3 Mel Gorman
2009-11-12 19:30 ` [PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed Mel Gorman
2009-11-13 5:23 ` KOSAKI Motohiro
2009-11-13 13:55 ` Mel Gorman
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=20091027122707.GD8900@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=bzolnier@gmail.com \
--cc=davem@davemloft.net \
--cc=elendil@planet.nl \
--cc=gregkh@suse.de \
--cc=jens.axboe@oracle.com \
--cc=jkosina@suse.cz \
--cc=kalle.valo@iki.fi \
--cc=karol.k.lewandowski@gmail.com \
--cc=kernel-testers@vger.kernel.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linville@tuxdriver.com \
--cc=lists@fuchsschwanzdomain.de \
--cc=mohamed.abbas@intel.com \
--cc=netdev@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=reinette.chatre@intel.com \
--cc=rientjes@google.com \
--cc=rjw@sisk.pl \
--cc=skraw@ithnet.com \
--cc=tobi@oetiker.ch \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox