rpms/kernel
3
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

remove unreferenced patches

Browse Source
This commit is contained in:
Dave Jones 2012-01-30 14:16:25 -05:00
parent ec7325df62
commit 2fd5228fc7
3 changed files with 0 additions and 199 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

81
0002-mm-Abort-reclaim-compaction-if-compaction-can-procee.patch
View File

@ -1,81 +0,0 @@
From c01043c9aa51a63bd01c60e53494ca4a7e994542 Mon Sep 17 00:00:00 2001
From: Mel Gorman <mgorman@suse.de>
Date: Fri, 7 Oct 2011 16:17:23 +0100
Subject: [PATCH 2/2] mm: Abort reclaim/compaction if compaction can proceed
If compaction can proceed, shrink_zones() stops doing any work but
the callers still shrink_slab(), raises the priority and potentially
sleeps. This patch aborts direct reclaim/compaction entirely if
compaction can proceed.
Signed-off-by: Mel Gorman <mgorman@suse.de>
---
mm/vmscan.c | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 8c03534..b295a38 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2000,14 +2000,19 @@ restart:
*
* If a zone is deemed to be full of pinned pages then just give it a light
* scan then give up on it.
+ *
+ * This function returns true if a zone is being reclaimed for a costly
+ * high-order allocation and compaction is either ready to begin or deferred.
+ * This indicates to the caller that it should retry the allocation or fail.
*/
-static void shrink_zones(int priority, struct zonelist *zonelist,
+static bool shrink_zones(int priority, struct zonelist *zonelist,
struct scan_control *sc)
{
struct zoneref *z;
struct zone *zone;
unsigned long nr_soft_reclaimed;
unsigned long nr_soft_scanned;
+ bool should_abort_reclaim = false;
for_each_zone_zonelist_nodemask(zone, z, zonelist,
gfp_zone(sc->gfp_mask), sc->nodemask) {
@@ -2025,12 +2030,15 @@ static void shrink_zones(int priority, struct zonelist *zonelist,
if (COMPACTION_BUILD) {
/*
* If we already have plenty of memory free
- * for compaction, don't free any more.
+ * for compaction in this zone , don't free any
+ * more.
*/
if (sc->order > PAGE_ALLOC_COSTLY_ORDER &&
(compaction_suitable(zone, sc->order) ||
- compaction_deferred(zone)))
+ compaction_deferred(zone))) {
+ should_abort_reclaim = true;
continue;
+ }
}
/*
* This steals pages from memory cgroups over softlimit
@@ -2049,6 +2057,8 @@ static void shrink_zones(int priority, struct zonelist *zonelist,
shrink_zone(priority, zone, sc);
}
+
+ return should_abort_reclaim;
}
static bool zone_reclaimable(struct zone *zone)
@@ -2113,7 +2123,9 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
sc->nr_scanned = 0;
if (!priority)
disable_swap_token(sc->mem_cgroup);
- shrink_zones(priority, zonelist, sc);
+ if (shrink_zones(priority, zonelist, sc))
+ break;
+
/*
* Don't shrink slabs when reclaiming memory from
* over limit cgroups
--
1.7.6.4

3
kernel.spec
View File

@ -757,9 +757,6 @@ Patch20000: utrace.patch
Patch21000: arm-omap-dt-compat.patch
Patch21001: arm-smsc-support-reading-mac-address-from-device-tree.patch
Patch21021: 0002-mm-Abort-reclaim-compaction-if-compaction-can-procee.patch
Patch21022: mm-do-not-stall-in-synchronous-compaction-for-THP-allocations.patch
#rhbz 717735
Patch21045: nfs-client-freezer.patch

115
mm-do-not-stall-in-synchronous-compaction-for-THP-allocations.patch
View File

@ -1,115 +0,0 @@
https://lkml.org/lkml/2011/11/10/173
Date Thu, 10 Nov 2011 10:06:16 +0000
From Mel Gorman <>
Subject [PATCH] mm: Do not stall in synchronous compaction for THP allocations
Occasionally during large file copies to slow storage, there are still
reports of user-visible stalls when THP is enabled. Reports on this
have been intermittent and not reliable to reproduce locally but;
Andy Isaacson reported a problem copying to VFAT on SD Card
https://lkml.org/lkml/2011/11/7/2
In this case, it was stuck in munmap for betwen 20 and 60
seconds in compaction. It is also possible that khugepaged
was holding mmap_sem on this process if CONFIG_NUMA was set.
Johannes Weiner reported stalls on USB
https://lkml.org/lkml/2011/7/25/378
In this case, there is no stack trace but it looks like the
same problem. The USB stick may have been using NTFS as a
filesystem based on other work done related to writing back
to USB around the same time.
Internally in SUSE, I received a bug report related to stalls in firefox
when using Java and Flash heavily while copying from NFS
to VFAT on USB. It has not been confirmed to be the same problem
but if it looks like a duck and quacks like a duck.....
In the past, commit [11bc82d6: mm: compaction: Use async migration for
__GFP_NO_KSWAPD and enforce no writeback] forced that sync compaction
would never be used for THP allocations. This was reverted in commit
[c6a140bf: mm/compaction: reverse the change that forbade sync
migraton with __GFP_NO_KSWAPD] on the grounds that it was uncertain
it was beneficial.
While user-visible stalls do not happen for me when writing to USB,
I setup a test running postmark while short-lived processes created
anonymous mapping. The objective was to exercise the paths that
allocate transparent huge pages. I then logged when processes were
stalled for more than 1 second, recorded a stack strace and did some
analysis to aggregate unique "stall events" which revealed
Time stalled in this event: 47369 ms
Event count: 20
usemem sleep_on_page 3690 ms
usemem sleep_on_page 2148 ms
usemem sleep_on_page 1534 ms
usemem sleep_on_page 1518 ms
usemem sleep_on_page 1225 ms
usemem sleep_on_page 2205 ms
usemem sleep_on_page 2399 ms
usemem sleep_on_page 2398 ms
usemem sleep_on_page 3760 ms
usemem sleep_on_page 1861 ms
usemem sleep_on_page 2948 ms
usemem sleep_on_page 1515 ms
usemem sleep_on_page 1386 ms
usemem sleep_on_page 1882 ms
usemem sleep_on_page 1850 ms
usemem sleep_on_page 3715 ms
usemem sleep_on_page 3716 ms
usemem sleep_on_page 4846 ms
usemem sleep_on_page 1306 ms
usemem sleep_on_page 1467 ms
[<ffffffff810ef30c>] wait_on_page_bit+0x6c/0x80
[<ffffffff8113de9f>] unmap_and_move+0x1bf/0x360
[<ffffffff8113e0e2>] migrate_pages+0xa2/0x1b0
[<ffffffff81134273>] compact_zone+0x1f3/0x2f0
[<ffffffff811345d8>] compact_zone_order+0xa8/0xf0
[<ffffffff811346ff>] try_to_compact_pages+0xdf/0x110
[<ffffffff810f773a>] __alloc_pages_direct_compact+0xda/0x1a0
[<ffffffff810f7d5d>] __alloc_pages_slowpath+0x55d/0x7a0
[<ffffffff810f8151>] __alloc_pages_nodemask+0x1b1/0x1c0
[<ffffffff811331db>] alloc_pages_vma+0x9b/0x160
[<ffffffff81142bb0>] do_huge_pmd_anonymous_page+0x160/0x270
[<ffffffff814410a7>] do_page_fault+0x207/0x4c0
[<ffffffff8143dde5>] page_fault+0x25/0x30
The stall times are approximate at best but the estimates represent 25%
of the worst stalls and even if the estimates are off by a factor of
10, it's severe.
This patch once again prevents sync migration for transparent
hugepage allocations as it is preferable to fail a THP allocation
than stall. It was suggested that __GFP_NORETRY be used instead of
__GFP_NO_KSWAPD. This would look less like a special case but would
still cause compaction to run at least once with sync compaction.
If accepted, this is a -stable candidate.
Reported-by: Andy Isaacson <adi@hexapodia.org>
Reported-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
---
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 9dd443d..84bf962 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2168,7 +2168,13 @@ rebalance:
sync_migration);
if (page)
goto got_pg;
- sync_migration = true;
+
+ /*
+ * Do not use sync migration for transparent hugepage allocations as
+ * it could stall writing back pages which is far worse than simply
+ * failing to promote a page.
+ */
+ sync_migration = !(gfp_mask & __GFP_NO_KSWAPD);
/* Try direct reclaim and then allocating */
page = __alloc_pages_direct_reclaim(gfp_mask, order,