From: Andrew Morton <akpm@linux-foundation.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Zlatko Calusic <zlatko.calusic@iskon.hr>,
Linus Torvalds <torvalds@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, linux-mm <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: do not sleep in balance_pgdat if there's no i/o congestion
Date: Thu, 20 Dec 2012 12:58:02 -0800 [thread overview]
Message-ID: <20121220125802.23e9b22d.akpm@linux-foundation.org> (raw)
In-Reply-To: <20121220111208.GD10819@suse.de>
On Thu, 20 Dec 2012 11:12:08 +0000
Mel Gorman <mgorman@suse.de> wrote:
> On Thu, Dec 20, 2012 at 12:17:07AM +0100, Zlatko Calusic wrote:
> > On a 4GB RAM machine, where Normal zone is much smaller than
> > DMA32 zone, the Normal zone gets fragmented in time. This requires
> > relatively more pressure in balance_pgdat to get the zone above the
> > required watermark. Unfortunately, the congestion_wait() call in there
> > slows it down for a completely wrong reason, expecting that there's
> > a lot of writeback/swapout, even when there's none (much more common).
> > After a few days, when fragmentation progresses, this flawed logic
> > translates to a very high CPU iowait times, even though there's no
> > I/O congestion at all. If THP is enabled, the problem occurs sooner,
> > but I was able to see it even on !THP kernels, just by giving it a bit
> > more time to occur.
> >
> > The proper way to deal with this is to not wait, unless there's
> > congestion. Thanks to Mel Gorman, we already have the function that
> > perfectly fits the job. The patch was tested on a machine which
> > nicely revealed the problem after only 1 day of uptime, and it's been
> > working great.
> > ---
> > mm/vmscan.c | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
>
> Acked-by: Mel Gorman <mgorman@suse.de
There seems to be some complexity/duplication here between the new
unbalanced_zone() and pgdat_balanced().
Can we modify pgdat_balanced() so that it also handles order=0, then do
- if (!unbalanced_zone || (order && pgdat_balanced(pgdat, balanced, *classzone_idx)))
+ if (!pgdat_balanced(...))
?
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Zlatko Calusic <zlatko.calusic@iskon.hr>,
Linus Torvalds <torvalds@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, linux-mm <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: do not sleep in balance_pgdat if there's no i/o congestion
Date: Thu, 20 Dec 2012 12:58:02 -0800 [thread overview]
Message-ID: <20121220125802.23e9b22d.akpm@linux-foundation.org> (raw)
In-Reply-To: <20121220111208.GD10819@suse.de>
On Thu, 20 Dec 2012 11:12:08 +0000
Mel Gorman <mgorman@suse.de> wrote:
> On Thu, Dec 20, 2012 at 12:17:07AM +0100, Zlatko Calusic wrote:
> > On a 4GB RAM machine, where Normal zone is much smaller than
> > DMA32 zone, the Normal zone gets fragmented in time. This requires
> > relatively more pressure in balance_pgdat to get the zone above the
> > required watermark. Unfortunately, the congestion_wait() call in there
> > slows it down for a completely wrong reason, expecting that there's
> > a lot of writeback/swapout, even when there's none (much more common).
> > After a few days, when fragmentation progresses, this flawed logic
> > translates to a very high CPU iowait times, even though there's no
> > I/O congestion at all. If THP is enabled, the problem occurs sooner,
> > but I was able to see it even on !THP kernels, just by giving it a bit
> > more time to occur.
> >
> > The proper way to deal with this is to not wait, unless there's
> > congestion. Thanks to Mel Gorman, we already have the function that
> > perfectly fits the job. The patch was tested on a machine which
> > nicely revealed the problem after only 1 day of uptime, and it's been
> > working great.
> > ---
> > mm/vmscan.c | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
>
> Acked-by: Mel Gorman <mgorman@suse.de
There seems to be some complexity/duplication here between the new
unbalanced_zone() and pgdat_balanced().
Can we modify pgdat_balanced() so that it also handles order=0, then do
- if (!unbalanced_zone || (order && pgdat_balanced(pgdat, balanced, *classzone_idx)))
+ if (!pgdat_balanced(...))
?
next prev parent reply other threads:[~2012-12-20 20:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-19 23:17 [PATCH] mm: do not sleep in balance_pgdat if there's no i/o congestion Zlatko Calusic
2012-12-19 23:17 ` Zlatko Calusic
2012-12-19 23:25 ` Zlatko Calusic
2012-12-19 23:25 ` Zlatko Calusic
2012-12-21 11:51 ` Hillf Danton
2012-12-21 11:51 ` Hillf Danton
2012-12-27 15:42 ` Zlatko Calusic
2012-12-27 15:42 ` Zlatko Calusic
2012-12-29 7:25 ` Hillf Danton
2012-12-29 7:25 ` Hillf Danton
2012-12-29 12:11 ` Zlatko Calusic
2012-12-29 12:11 ` Zlatko Calusic
2012-12-20 11:12 ` Mel Gorman
2012-12-20 11:12 ` Mel Gorman
2012-12-20 20:58 ` Andrew Morton [this message]
2012-12-20 20:58 ` Andrew Morton
2012-12-22 18:54 ` [PATCH] mm: modify pgdat_balanced() so that it also handles order=0 Zlatko Calusic
2012-12-22 18:54 ` Zlatko Calusic
2012-12-23 14:12 ` [PATCH v2] " Zlatko Calusic
2012-12-23 14:12 ` Zlatko Calusic
2012-12-26 15:07 ` [PATCH] mm: avoid calling pgdat_balanced() needlessly Zlatko Calusic
2012-12-26 15:07 ` Zlatko Calusic
2012-12-28 2:16 ` [PATCH] mm: fix null pointer dereference in wait_iff_congested() Zlatko Calusic
2012-12-28 2:16 ` Zlatko Calusic
2012-12-28 2:49 ` Minchan Kim
2012-12-28 2:49 ` Minchan Kim
2012-12-28 13:29 ` Zlatko Calusic
2012-12-28 13:29 ` Zlatko Calusic
2012-12-31 0:50 ` Minchan Kim
2012-12-31 0:50 ` Minchan Kim
2012-12-29 8:45 ` Sedat Dilek
2012-12-29 8:45 ` Sedat Dilek
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=20121220125802.23e9b22d.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=torvalds@linux-foundation.org \
--cc=zlatko.calusic@iskon.hr \
/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.