public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frans Pop <elendil@planet.nl>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jiri Kosina <jkosina@suse.cz>,
	Sven Geggus <lists@fuchsschwanzdomain.de>,
	Karol Lewandowski <karol.k.lewandowski@gmail.com>,
	Tobias Oetiker <tobi@oetiker.ch>,
	linux-kernel@vger.kernel.org,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	Rik van Riel <riel@redhat.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Stephan von Krawczynski <skraw@ithnet.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Kernel Testers List <kernel-testers@vger.kernel.org>,
	Chris Mason <chris.mason@oracle.com>
Subject: Re: [PATCH 0/5] Reduce GFP_ATOMIC allocation failures, candidate fix V3
Date: Fri, 13 Nov 2009 10:04:21 +0100	[thread overview]
Message-ID: <200911131004.25293.elendil@planet.nl> (raw)
In-Reply-To: <1258054235-3208-1-git-send-email-mel@csn.ul.ie>

On Thursday 12 November 2009, Mel Gorman wrote:
> Changelog since V2
>   o Dropped the kswapd-quickly-notice-high-order patch. In more detailed
>     testing, it made latencies even worse as kswapd slept more on
>     high-order congestion causing order-0 direct reclaims.
>   o Added changes to how congestion_wait() works
>   o Added a number of new patches altering the behaviour of reclaim

I have tested this series on top of .32-rc7. First impression is that it 
does seem to improve my test case, but does not yet completely solve it.

My last gitk instance now loads more smoothly for most of the time it takes 
to complete, but I still see a choke point where things freeze for a while 
and where I get SKB allocation errors from my wireless.
However, that choke point does seem to happen later and to be shorter than 
without the patches.

I'll try to do additional tests (with .31). If you'd like me to run this 
set with your instrumentation patch for congestion_wait, then please let 
me know.

Chris Mason's analysis regarding dm-crypt workqueues in reply to your other 
mail looks very interesting.

Cheers,
FJP

  parent reply	other threads:[~2009-11-13  9:04 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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
2009-11-12 19:30 ` [PATCH 2/5] page allocator: Do not allow interrupts to use ALLOC_HARDER Mel Gorman
2009-11-13  5:24   ` KOSAKI Motohiro
2009-11-13 13:56     ` Mel Gorman
2009-11-12 19:30 ` [PATCH 3/5] page allocator: Wait on both sync and async congestion after direct reclaim Mel Gorman
2009-11-13 11:20   ` KOSAKI Motohiro
2009-11-13 11:55     ` Jens Axboe
2009-11-13 12:28       ` Mel Gorman
2009-11-13 13:32         ` Jens Axboe
2009-11-13 13:41           ` Pekka Enberg
2009-11-13 15:22             ` Chris Mason
2009-11-13 14:16           ` Mel Gorman
2009-11-20 14:56           ` Mel Gorman
2009-11-12 19:30 ` [PATCH 4/5] vmscan: Have kswapd sleep for a short interval and double check it should be asleep Mel Gorman
2009-11-13 10:43   ` KOSAKI Motohiro
2009-11-13 14:13     ` Mel Gorman
2009-11-13 18:00       ` KOSAKI Motohiro
2009-11-13 18:17         ` Mel Gorman
2009-11-14  9:34           ` KOSAKI Motohiro
2009-11-14 15:46             ` Mel Gorman
2009-11-17 11:03               ` KOSAKI Motohiro
2009-11-17 11:44                 ` Mel Gorman
2009-11-17 12:18                   ` KOSAKI Motohiro
2009-11-17 12:25                     ` Mel Gorman
2009-11-18  5:20                       ` KOSAKI Motohiro
2009-11-17 10:34             ` [PATCH] vmscan: Have kswapd sleep for a short interval and double check it should be asleep fix 1 Mel Gorman
2009-11-18  5:27               ` KOSAKI Motohiro
2009-11-12 19:30 ` [PATCH 5/5] vmscan: Take order into consideration when deciding if kswapd is in trouble Mel Gorman
2009-11-13  9:54   ` KOSAKI Motohiro
2009-11-13 13:54     ` Mel Gorman
2009-11-13 14:48       ` Minchan Kim
2009-11-13 18:00       ` KOSAKI Motohiro
2009-11-13 18:15         ` [PATCH] vmscan: Stop kswapd waiting on congestion when the min watermark is not being met Mel Gorman
2009-11-13 18:26           ` Frans Pop
2009-11-13 18:33           ` KOSAKI Motohiro
2009-11-13 20:03             ` [PATCH] vmscan: Stop kswapd waiting on congestion when the min watermark is not being met V2 Mel Gorman
2009-11-26 14:45               ` Tobias Oetiker
2009-11-29  7:42                 ` still getting allocation failures (was Re: [PATCH] vmscan: Stop kswapd waiting on congestion when the min watermark is not being met V2) Tobi Oetiker
2009-12-02 11:32                   ` Mel Gorman
2009-12-02 21:30                     ` Tobias Oetiker
2009-12-03 20:26                       ` Corrado Zoccolo
2009-12-14  5:59                         ` Tobias Oetiker
2009-12-14  8:49                           ` Corrado Zoccolo
2009-11-13 18:36           ` [PATCH] vmscan: Stop kswapd waiting on congestion when the min watermark is not being met Rik van Riel
2009-11-13 14:38     ` [PATCH 5/5] vmscan: Take order into consideration when deciding if kswapd is in trouble Minchan Kim
2009-11-13 12:41   ` Minchan Kim
2009-11-13  9:04 ` Frans Pop [this message]
2009-11-16 17:57   ` [PATCH 0/5] Reduce GFP_ATOMIC allocation failures, candidate fix V3 Mel Gorman
2009-11-13 12:47 ` Tobias Oetiker
2009-11-13 13:37   ` Mel Gorman
2009-11-15 12:07 ` Karol Lewandowski
2009-11-16  9:52   ` Mel Gorman
2009-11-16 12:08     ` Karol Lewandowski
2009-11-16 14:32       ` Karol Lewandowski

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=200911131004.25293.elendil@planet.nl \
    --to=elendil@planet.nl \
    --cc=akpm@linux-foundation.org \
    --cc=chris.mason@oracle.com \
    --cc=cl@linux-foundation.org \
    --cc=jkosina@suse.cz \
    --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=lists@fuchsschwanzdomain.de \
    --cc=mel@csn.ul.ie \
    --cc=penberg@cs.helsinki.fi \
    --cc=riel@redhat.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