vmscan-limit-direct-reclaim-for-higher-order-allocations-fix

change comment to explain the order check

Signed-off-by: Johannes Weiner <jweiner@redhat.com>
Cc: Johannes Weiner <jweiner@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 78172f16f62a61da60c4fcf3603e6a535946f6ed..1b9a027c1984499733b156240e9c5b3593330994 100644 (file)
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2115,8 +2115,14 @@ static void shrink_zones(int priority, struct zonelist *zonelist,
                                continue;       /* Let kswapd poll it */
                        if (COMPACTION_BUILD) {
                                /*
-                                * If we already have plenty of memory free
-                                * for compaction, don't free any more.
+                                * If we already have plenty of memory
+                                * free for compaction, don't free any
+                                * more.  Even though compaction is
+                                * invoked for any non-zero order,
+                                * only frequent costly order
+                                * reclamation is disruptive enough to
+                                * become a noticable problem, like
+                                * transparent huge page allocations.
                                 */
                                if (sc->order > PAGE_ALLOC_COSTLY_ORDER &&
                                        (compaction_suitable(zone, sc->order) ||