53 lines
2.2 KiB
Diff
53 lines
2.2 KiB
Diff
From linux-fsdevel-owner@vger.kernel.org Fri May 13 10:04:00 2011
|
|
From: Mel Gorman <mgorman@suse.de>
|
|
To: Andrew Morton <akpm@linux-foundation.org>
|
|
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
|
|
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>,
|
|
Mel Gorman <mgorman@suse.de>
|
|
Subject: [PATCH 2/4] mm: slub: Do not wake kswapd for SLUBs speculative high-order allocations
|
|
Date: Fri, 13 May 2011 15:03:22 +0100
|
|
Message-Id: <1305295404-12129-3-git-send-email-mgorman@suse.de>
|
|
X-Mailing-List: linux-fsdevel@vger.kernel.org
|
|
|
|
To avoid locking and per-cpu overhead, SLUB optimisically uses
|
|
high-order allocations and falls back to lower allocations if they
|
|
fail. However, by simply trying to allocate, kswapd is woken up to
|
|
start reclaiming at that order. On a desktop system, two users report
|
|
that the system is getting locked up with kswapd using large amounts
|
|
of CPU. Using SLAB instead of SLUB made this problem go away.
|
|
|
|
This patch prevents kswapd being woken up for high-order allocations.
|
|
Testing indicated that with this patch applied, the system was much
|
|
harder to hang and even when it did, it eventually recovered.
|
|
|
|
Signed-off-by: Mel Gorman <mgorman@suse.de>
|
|
---
|
|
mm/slub.c | 2 +-
|
|
1 files changed, 1 insertions(+), 1 deletions(-)
|
|
|
|
diff --git a/mm/slub.c b/mm/slub.c
|
|
index 9d2e5e4..98c358d 100644
|
|
--- a/mm/slub.c
|
|
+++ b/mm/slub.c
|
|
@@ -1170,7 +1170,7 @@ static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
|
|
* Let the initial higher-order allocation fail under memory pressure
|
|
* so we fall-back to the minimum order allocation.
|
|
*/
|
|
- alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY) & ~__GFP_NOFAIL;
|
|
+ alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY | __GFP_NO_KSWAPD) & ~__GFP_NOFAIL;
|
|
|
|
page = alloc_slab_page(alloc_gfp, node, oo);
|
|
if (unlikely(!page)) {
|
|
--
|
|
1.7.3.4
|