From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Colin King <colin.king@canonical.com>,
Raghavendra D Prabhu <raghu.prabhu13@gmail.com>,
Jan Kara <jack@suse.cz>, Chris Mason <chris.mason@oracle.com>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>, Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 0/4] Reduce impact to overall system of SLUB using high-order allocations V2
Date: Fri, 13 May 2011 10:19:44 -0500 [thread overview]
Message-ID: <1305299984.2611.37.camel@mulgrave.site> (raw)
In-Reply-To: <1305295404-12129-1-git-send-email-mgorman@suse.de>
On Fri, 2011-05-13 at 15:03 +0100, Mel Gorman wrote:
> Changelog since V1
> o kswapd should sleep if need_resched
> o Remove __GFP_REPEAT from GFP flags when speculatively using high
> orders so direct/compaction exits earlier
> o Remove __GFP_NORETRY for correctness
> o Correct logic in sleeping_prematurely
> o Leave SLUB using the default slub_max_order
>
> There are a few reports of people experiencing hangs when copying
> large amounts of data with kswapd using a large amount of CPU which
> appear to be due to recent reclaim changes.
>
> SLUB using high orders is the trigger but not the root cause as SLUB
> has been using high orders for a while. The following four patches
> aim to fix the problems in reclaim while reducing the cost for SLUB
> using those high orders.
>
> Patch 1 corrects logic introduced by commit [1741c877: mm:
> kswapd: keep kswapd awake for high-order allocations until
> a percentage of the node is balanced] to allow kswapd to
> go to sleep when balanced for high orders.
>
> Patch 2 prevents kswapd waking up in response to SLUBs speculative
> use of high orders.
>
> Patch 3 further reduces the cost by prevent SLUB entering direct
> compaction or reclaim paths on the grounds that falling
> back to order-0 should be cheaper.
>
> Patch 4 notes that even when kswapd is failing to keep up with
> allocation requests, it should still go to sleep when its
> quota has expired to prevent it spinning.
This all works fine for me ... three untar runs and no kswapd hangs or
pegging the CPU at 99% ... in fact, kswapd rarely gets over 20%
This isn't as good as the kswapd sleeping_prematurely() throttling
patch. For total CPU time on a three 90GB untar run, it's about 64s of
CPU time with your patch rather than 6s, but that's vastly better than
the 15 minutes of CPU time kswapd was taking even under PREEMPT.
James
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Colin King <colin.king@canonical.com>,
Raghavendra D Prabhu <raghu.prabhu13@gmail.com>,
Jan Kara <jack@suse.cz>, Chris Mason <chris.mason@oracle.com>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 0/4] Reduce impact to overall system of SLUB using high-order allocations V2
Date: Fri, 13 May 2011 10:19:44 -0500 [thread overview]
Message-ID: <1305299984.2611.37.camel@mulgrave.site> (raw)
In-Reply-To: <1305295404-12129-1-git-send-email-mgorman@suse.de>
On Fri, 2011-05-13 at 15:03 +0100, Mel Gorman wrote:
> Changelog since V1
> o kswapd should sleep if need_resched
> o Remove __GFP_REPEAT from GFP flags when speculatively using high
> orders so direct/compaction exits earlier
> o Remove __GFP_NORETRY for correctness
> o Correct logic in sleeping_prematurely
> o Leave SLUB using the default slub_max_order
>
> There are a few reports of people experiencing hangs when copying
> large amounts of data with kswapd using a large amount of CPU which
> appear to be due to recent reclaim changes.
>
> SLUB using high orders is the trigger but not the root cause as SLUB
> has been using high orders for a while. The following four patches
> aim to fix the problems in reclaim while reducing the cost for SLUB
> using those high orders.
>
> Patch 1 corrects logic introduced by commit [1741c877: mm:
> kswapd: keep kswapd awake for high-order allocations until
> a percentage of the node is balanced] to allow kswapd to
> go to sleep when balanced for high orders.
>
> Patch 2 prevents kswapd waking up in response to SLUBs speculative
> use of high orders.
>
> Patch 3 further reduces the cost by prevent SLUB entering direct
> compaction or reclaim paths on the grounds that falling
> back to order-0 should be cheaper.
>
> Patch 4 notes that even when kswapd is failing to keep up with
> allocation requests, it should still go to sleep when its
> quota has expired to prevent it spinning.
This all works fine for me ... three untar runs and no kswapd hangs or
pegging the CPU at 99% ... in fact, kswapd rarely gets over 20%
This isn't as good as the kswapd sleeping_prematurely() throttling
patch. For total CPU time on a three 90GB untar run, it's about 64s of
CPU time with your patch rather than 6s, but that's vastly better than
the 15 minutes of CPU time kswapd was taking even under PREEMPT.
James
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Colin King <colin.king@canonical.com>,
Raghavendra D Prabhu <raghu.prabhu13@gmail.com>,
Jan Kara <jack@suse.cz>, Chris Mason <chris.mason@oracle.com>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>, Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 0/4] Reduce impact to overall system of SLUB using high-order allocations V2
Date: Fri, 13 May 2011 10:19:44 -0500 [thread overview]
Message-ID: <1305299984.2611.37.camel@mulgrave.site> (raw)
In-Reply-To: <1305295404-12129-1-git-send-email-mgorman@suse.de>
On Fri, 2011-05-13 at 15:03 +0100, Mel Gorman wrote:
> Changelog since V1
> o kswapd should sleep if need_resched
> o Remove __GFP_REPEAT from GFP flags when speculatively using high
> orders so direct/compaction exits earlier
> o Remove __GFP_NORETRY for correctness
> o Correct logic in sleeping_prematurely
> o Leave SLUB using the default slub_max_order
>
> There are a few reports of people experiencing hangs when copying
> large amounts of data with kswapd using a large amount of CPU which
> appear to be due to recent reclaim changes.
>
> SLUB using high orders is the trigger but not the root cause as SLUB
> has been using high orders for a while. The following four patches
> aim to fix the problems in reclaim while reducing the cost for SLUB
> using those high orders.
>
> Patch 1 corrects logic introduced by commit [1741c877: mm:
> kswapd: keep kswapd awake for high-order allocations until
> a percentage of the node is balanced] to allow kswapd to
> go to sleep when balanced for high orders.
>
> Patch 2 prevents kswapd waking up in response to SLUBs speculative
> use of high orders.
>
> Patch 3 further reduces the cost by prevent SLUB entering direct
> compaction or reclaim paths on the grounds that falling
> back to order-0 should be cheaper.
>
> Patch 4 notes that even when kswapd is failing to keep up with
> allocation requests, it should still go to sleep when its
> quota has expired to prevent it spinning.
This all works fine for me ... three untar runs and no kswapd hangs or
pegging the CPU at 99% ... in fact, kswapd rarely gets over 20%
This isn't as good as the kswapd sleeping_prematurely() throttling
patch. For total CPU time on a three 90GB untar run, it's about 64s of
CPU time with your patch rather than 6s, but that's vastly better than
the 15 minutes of CPU time kswapd was taking even under PREEMPT.
James
--
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-13 15:19 UTC|newest]
Thread overview: 119+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-13 14:03 [PATCH 0/4] Reduce impact to overall system of SLUB using high-order allocations V2 Mel Gorman
2011-05-13 14:03 ` Mel Gorman
2011-05-13 14:03 ` [PATCH 1/4] mm: vmscan: Correct use of pgdat_balanced in sleeping_prematurely Mel Gorman
2011-05-13 14:03 ` Mel Gorman
2011-05-13 14:28 ` Johannes Weiner
2011-05-13 14:28 ` Johannes Weiner
2011-05-14 16:30 ` Minchan Kim
2011-05-14 16:30 ` Minchan Kim
2011-05-16 14:30 ` Rik van Riel
2011-05-16 14:30 ` Rik van Riel
2011-05-13 14:03 ` [PATCH 2/4] mm: slub: Do not wake kswapd for SLUBs speculative high-order allocations Mel Gorman
2011-05-13 14:03 ` Mel Gorman
2011-05-16 21:10 ` David Rientjes
2011-05-16 21:10 ` David Rientjes
2011-05-18 6:09 ` Pekka Enberg
2011-05-18 6:09 ` Pekka Enberg
2011-05-18 17:21 ` Christoph Lameter
2011-05-18 17:21 ` Christoph Lameter
2011-05-13 14:03 ` [PATCH 3/4] mm: slub: Do not take expensive steps " Mel Gorman
2011-05-13 14:03 ` Mel Gorman
2011-05-16 21:16 ` David Rientjes
2011-05-16 21:16 ` David Rientjes
2011-05-17 8:42 ` Mel Gorman
2011-05-17 8:42 ` Mel Gorman
2011-05-17 13:51 ` Christoph Lameter
2011-05-17 13:51 ` Christoph Lameter
2011-05-17 16:22 ` Mel Gorman
2011-05-17 16:22 ` Mel Gorman
2011-05-17 17:52 ` Christoph Lameter
2011-05-17 17:52 ` Christoph Lameter
2011-05-17 19:35 ` David Rientjes
2011-05-17 19:35 ` David Rientjes
2011-05-17 19:31 ` David Rientjes
2011-05-17 19:31 ` David Rientjes
2011-05-13 14:03 ` [PATCH 4/4] mm: vmscan: If kswapd has been running too long, allow it to sleep Mel Gorman
2011-05-13 14:03 ` Mel Gorman
2011-05-15 10:27 ` KOSAKI Motohiro
2011-05-15 10:27 ` KOSAKI Motohiro
2011-05-16 4:21 ` James Bottomley
2011-05-16 4:21 ` James Bottomley
2011-05-16 5:04 ` Minchan Kim
2011-05-16 5:04 ` Minchan Kim
2011-05-16 8:45 ` Mel Gorman
2011-05-16 8:45 ` Mel Gorman
2011-05-16 8:45 ` Mel Gorman
2011-05-16 8:58 ` Minchan Kim
2011-05-16 8:58 ` Minchan Kim
2011-05-16 8:58 ` Minchan Kim
2011-05-16 10:27 ` Mel Gorman
2011-05-16 10:27 ` Mel Gorman
2011-05-16 10:27 ` Mel Gorman
2011-05-16 23:50 ` Minchan Kim
2011-05-16 23:50 ` Minchan Kim
2011-05-17 0:48 ` Minchan Kim
2011-05-17 0:48 ` Minchan Kim
2011-05-17 0:48 ` Minchan Kim
2011-05-17 10:38 ` Mel Gorman
2011-05-17 10:38 ` Mel Gorman
2011-05-17 10:38 ` Mel Gorman
2011-05-17 13:50 ` Colin Ian King
2011-05-17 13:50 ` Colin Ian King
2011-05-17 16:15 ` [PATCH] mm: vmscan: Correctly check if reclaimer should schedule during shrink_slab Mel Gorman
2011-05-17 16:15 ` Mel Gorman
2011-05-18 0:45 ` KOSAKI Motohiro
2011-05-18 0:45 ` KOSAKI Motohiro
2011-05-19 0:03 ` Minchan Kim
2011-05-19 0:03 ` Minchan Kim
2011-05-19 0:03 ` Minchan Kim
2011-05-19 0:09 ` Minchan Kim
2011-05-19 0:09 ` Minchan Kim
2011-05-19 0:09 ` Minchan Kim
2011-05-19 11:36 ` Colin Ian King
2011-05-19 11:36 ` Colin Ian King
2011-05-20 0:06 ` Minchan Kim
2011-05-20 0:06 ` Minchan Kim
2011-05-20 0:06 ` Minchan Kim
2011-05-18 4:19 ` [PATCH 4/4] mm: vmscan: If kswapd has been running too long, allow it to sleep Minchan Kim
2011-05-18 4:19 ` Minchan Kim
2011-05-18 7:39 ` Colin Ian King
2011-05-18 7:39 ` Colin Ian King
2011-05-18 4:09 ` James Bottomley
2011-05-18 4:09 ` James Bottomley
2011-05-18 1:05 ` KOSAKI Motohiro
2011-05-18 1:05 ` KOSAKI Motohiro
2011-05-18 5:44 ` Minchan Kim
2011-05-18 5:44 ` Minchan Kim
2011-05-18 5:44 ` Minchan Kim
2011-05-18 6:05 ` KOSAKI Motohiro
2011-05-18 6:05 ` KOSAKI Motohiro
2011-05-18 9:58 ` Mel Gorman
2011-05-18 9:58 ` Mel Gorman
2011-05-18 9:58 ` Mel Gorman
2011-05-18 22:55 ` Minchan Kim
2011-05-18 22:55 ` Minchan Kim
2011-05-18 23:54 ` KOSAKI Motohiro
2011-05-18 23:54 ` KOSAKI Motohiro
2011-05-18 0:26 ` KOSAKI Motohiro
2011-05-18 0:26 ` KOSAKI Motohiro
2011-05-18 9:57 ` Mel Gorman
2011-05-18 9:57 ` Mel Gorman
2011-05-16 8:45 ` Mel Gorman
2011-05-16 8:45 ` Mel Gorman
2011-05-16 14:30 ` Rik van Riel
2011-05-16 14:30 ` Rik van Riel
2011-05-13 15:19 ` James Bottomley [this message]
2011-05-13 15:19 ` [PATCH 0/4] Reduce impact to overall system of SLUB using high-order allocations V2 James Bottomley
2011-05-13 15:19 ` James Bottomley
2011-05-13 15:52 ` Mel Gorman
2011-05-13 15:52 ` Mel Gorman
2011-05-13 15:21 ` Christoph Lameter
2011-05-13 15:21 ` Christoph Lameter
2011-05-13 15:43 ` Mel Gorman
2011-05-13 15:43 ` Mel Gorman
2011-05-14 8:34 ` Colin Ian King
2011-05-14 8:34 ` Colin Ian King
2011-05-16 8:37 ` Mel Gorman
2011-05-16 8:37 ` Mel Gorman
2011-05-16 11:24 ` Colin Ian King
2011-05-16 11:24 ` Colin Ian King
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=1305299984.2611.37.camel@mulgrave.site \
--to=james.bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=chris.mason@oracle.com \
--cc=cl@linux.com \
--cc=colin.king@canonical.com \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=penberg@kernel.org \
--cc=raghu.prabhu13@gmail.com \
--cc=riel@redhat.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.