linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Frans Pop <elendil@planet.nl>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	stable@kernel.org, linux-kernel@vger.kernel.org,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Jiri Kosina <jkosina@suse.cz>,
	Sven Geggus <lists@fuchsschwanzdomain.de>,
	Karol Lewandowski <karol.k.lewandowski@gmail.com>,
	Tobias Oetiker <tobi@oetiker.ch>,
	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>,
	Kernel Testers List <kernel-testers@vger.kernel.org>
Subject: Re: [PATCH 3/3] vmscan: Force kswapd to take notice faster when high-order watermarks are being hit
Date: Wed, 4 Nov 2009 15:48:53 +0000	[thread overview]
Message-ID: <20091104154853.GM22046@csn.ul.ie> (raw)
In-Reply-To: <200911040305.59352.elendil@planet.nl>

On Wed, Nov 04, 2009 at 03:05:55AM +0100, Frans Pop wrote:
> On Wednesday 04 November 2009, Mel Gorman wrote:
> > > If you'd like me to test with the congestion_wait() revert on top of
> > > this for comparison, please let me know.
> >
> > No, there is resistance to rolling back the congestion_wait() changes
> 
> I've never promoted the revert as a solution. It just shows the cause of a 
> regression.
> 

Yeah, I still haven't managed to figure out what exactly is wrong in there
other than "something changed with timing" and writeback behaves differently. I
still don't know the why of it because I haven't digged into that area in
depth in the past and failed at reproducing this. "My desktop is fine" :/

> > from what I gather because they were introduced for sane reasons. The
> > consequence is just that the reliability of high-order atomics are
> > impacted because more processes are making forward progress where
> > previously they would have waited until kswapd had done work. Your
> > driver has already been fixed in this regard and maybe it's a case that
> > the other atomic users simply have to be fixed to "not do that".
> 
> The problem is that although my driver has been fixed so that it no longer 
> causes the SKB allocation errors, the also rather serious behavior change 
> where due to swapping my 3rd gitk takes up to twice as long to load with 
> desktop freezes of up 45 seconds or so is still there.
> 
> Although that's somewhat separate from the issue that started this whole 
> investigation, I still feel that should be sorted out as well.
> 

You're right. That behaviour sucks.

> The congestion_wait() change, even if theoretically valid, introduced a 
> very real regression IMO. Such long desktop freezes during swapping should 
> be avoided; .30 and earlier simply behaved a whole lot better in the same 
> situation.
> 

Agreed. I'll start from scratch again trying to reproduce what you're seeing
locally. I'll try breaking my network card so that it's making high-order
atomics and see where I get. Machines that were previously tied up are now
free so I might have a better chance.

-- 
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>

  parent reply	other threads:[~2009-11-04 15:49 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-27 13:40 [PATCH 0/3] Reduce GFP_ATOMIC allocation failures, partial fix V3 Mel Gorman
2009-10-27 13:40 ` [PATCH 1/3] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed Mel Gorman
2009-10-27 13:40 ` [PATCH 2/3] page allocator: Do not allow interrupts to use ALLOC_HARDER Mel Gorman
     [not found]   ` <1256650833-15516-3-git-send-email-mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
2009-10-27 20:09     ` Andrew Morton
2009-10-27 21:12       ` David Rientjes
2009-10-31 18:40         ` Pavel Machek
2009-10-31 19:51           ` David Rientjes
2009-10-31 20:11             ` Pavel Machek
2009-10-31 21:19               ` David Rientjes
2009-10-31 22:29                 ` Pavel Machek
2009-10-31 22:55                   ` Rik van Riel
2009-11-01  7:35                     ` Pavel Machek
2009-11-01 12:37                       ` KOSAKI Motohiro
2009-11-01 14:44                       ` Rik van Riel
2009-11-01 19:32                         ` Pavel Machek
2009-11-02 16:38                         ` Christoph Lameter
2009-10-31 23:59               ` Rik van Riel
2009-11-02 16:42                 ` Christoph Lameter
2009-11-02 20:53                   ` David Rientjes
2009-11-03 17:10                     ` Christoph Lameter
2009-11-04  1:46                       ` David Rientjes
2009-11-04  9:01                         ` Pavel Machek
2009-11-09 10:11                           ` Mel Gorman
2009-10-28 10:24       ` Mel Gorman
2009-10-27 13:40 ` [PATCH 3/3] vmscan: Force kswapd to take notice faster when high-order watermarks are being hit Mel Gorman
2009-10-27 18:18   ` Rik van Riel
2009-10-27 20:19   ` Andrew Morton
2009-10-28  3:54     ` KOSAKI Motohiro
2009-10-28 10:29     ` Mel Gorman
2009-10-28 19:47       ` Andrew Morton
2009-11-02 16:05         ` Mel Gorman
2009-11-02 17:32           ` Frans Pop
2009-11-02 17:38             ` Mel Gorman
2009-11-02 20:36               ` Mel Gorman
2009-11-03 22:01               ` Frans Pop
2009-11-03 22:08                 ` Mel Gorman
2009-11-04  0:01                   ` Frans Pop
2009-11-04  1:18                     ` Mel Gorman
2009-11-04  2:05                       ` Frans Pop
2009-11-04  2:08                         ` Frans Pop
2009-11-04 15:48                         ` Mel Gorman [this message]
2009-11-04 20:57                           ` Frans Pop
2009-11-05 16:48                             ` [PATCH 3/3] vmscan: Force kswapd to take notice faster when high-order watermarks are being hit (data on latencies available) Mel Gorman
2009-11-12 11:36                               ` Frans Pop
2009-11-04  2:08                       ` [PATCH 3/3] vmscan: Force kswapd to take notice faster when high-order watermarks are being hit Mel Gorman
2009-10-28 13:02 ` [PATCH 0/3] Reduce GFP_ATOMIC allocation failures, partial fix V3 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=20091104154853.GM22046@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=elendil@planet.nl \
    --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=penberg@cs.helsinki.fi \
    --cc=riel@redhat.com \
    --cc=skraw@ithnet.com \
    --cc=stable@kernel.org \
    --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