)]}' { "commit": "a77ebd333cd810d7b680d544be88c875131c2bd3", "tree": "f7e3baabdb4d81e089924e402442b21c4eaa3aab", "parents": [ "ea4d349ffa8028c655236497c2ba17c17aaa0d65" ], "author": { "name": "Mel Gorman", "email": "mgorman@suse.de", "time": "Thu Jan 12 17:19:22 2012 -0800" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@linux-foundation.org", "time": "Thu Jan 12 20:13:08 2012 -0800" }, "message": "mm: compaction: allow compaction to isolate dirty pages\n\nShort summary: There are severe stalls when a USB stick using VFAT is\nused with THP enabled that are reduced by this series. If you are\nexperiencing this problem, please test and report back and considering I\nhave seen complaints from openSUSE and Fedora users on this as well as a\nfew private mails, I\u0027m guessing it\u0027s a widespread issue. This is a new\ntype of USB-related stall because it is due to synchronous compaction\nwriting where as in the past the big problem was dirty pages reaching\nthe end of the LRU and being written by reclaim.\n\nAm cc\u0027ing Andrew this time and this series would replace\nmm-do-not-stall-in-synchronous-compaction-for-thp-allocations.patch.\nI\u0027m also cc\u0027ing Dave Jones as he might have merged that patch to Fedora\nfor wider testing and ideally it would be reverted and replaced by this\nseries.\n\nThat said, the later patches could really do with some review. If this\nseries is not the answer then a new direction needs to be discussed\nbecause as it is, the stalls are unacceptable as the results in this\nleader show.\n\nFor testers that try backporting this to 3.1, it won\u0027t work because\nthere is a non-obvious dependency on not writing back pages in direct\nreclaim so you need those patches too.\n\nChangelog since V5\no Rebase to 3.2-rc5\no Tidy up the changelogs a bit\n\nChangelog since V4\no Added reviewed-bys, credited Andrea properly for sync-light\no Allow dirty pages without mappings to be considered for migration\no Bound the number of pages freed for compaction\no Isolate PageReclaim pages on their own LRU list\n\nThis is against 3.2-rc5 and follows on from discussions on \"mm: Do\nnot stall in synchronous compaction for THP allocations\" and \"[RFC\nPATCH 0/5] Reduce compaction-related stalls\". Initially, the proposed\npatch eliminated stalls due to compaction which sometimes resulted in\nuser-visible interactivity problems on browsers by simply never using\nsync compaction. The downside was that THP success allocation rates\nwere lower because dirty pages were not being migrated as reported by\nAndrea. His approach at fixing this was nacked on the grounds that\nit reverted fixes from Rik merged that reduced the amount of pages\nreclaimed as it severely impacted his workloads performance.\n\nThis series attempts to reconcile the requirements of maximising THP\nusage, without stalling in a user-visible fashion due to compaction\nor cheating by reclaiming an excessive number of pages.\n\nPatch 1 partially reverts commit 39deaf85 to allow migration to isolate\n\tdirty pages. This is because migration can move some dirty\n\tpages without blocking.\n\nPatch 2 notes that the /proc/sys/vm/compact_memory handler is not using\n\tsynchronous compaction when it should be. This is unrelated\n\tto the reported stalls but is worth fixing.\n\nPatch 3 checks if we isolated a compound page during lumpy scan and\n\taccount for it properly. For the most part, this affects\n\ttracing so it\u0027s unrelated to the stalls but worth fixing.\n\nPatch 4 notes that it is possible to abort reclaim early for compaction\n\tand return 0 to the page allocator potentially entering the\n\t\"may oom\" path. This has not been observed in practice but\n\tthe rest of the series potentially makes it easier to happen.\n\nPatch 5 adds a sync parameter to the migratepage callback and gives\n\tthe callback responsibility for migrating the page without\n\tblocking if sync\u003d\u003dfalse. For example, fallback_migrate_page\n\twill not call writepage if sync\u003d\u003dfalse. This increases the\n\tnumber of pages that can be handled by asynchronous compaction\n\tthereby reducing stalls.\n\nPatch 6 restores filter-awareness to isolate_lru_page for migration.\n\tIn practice, it means that pages under writeback and pages\n\twithout a -\u003emigratepage callback will not be isolated\n\tfor migration.\n\nPatch 7 avoids calling direct reclaim if compaction is deferred but\n\tmakes sure that compaction is only deferred if sync\n\tcompaction was used.\n\nPatch 8 introduces a sync-light migration mechanism that sync compaction\n\tuses. The objective is to allow some stalls but to not call\n\t-\u003ewritepage which can lead to significant user-visible stalls.\n\nPatch 9 notes that while we want to abort reclaim ASAP to allow\n\tcompation to go ahead that we leave a very small window of\n\topportunity for compaction to run. This patch allows more pages\n\tto be freed by reclaim but bounds the number to a reasonable\n\tlevel based on the high watermark on each zone.\n\nPatch 10 allows slabs to be shrunk even after compaction_ready() is\n\ttrue for one zone. This is to avoid a problem whereby a single\n\tsmall zone can abort reclaim even though no pages have been\n\treclaimed and no suitably large zone is in a usable state.\n\nPatch 11 fixes a problem with the rate of page scanning. As reclaim is\n\trarely stalling on pages under writeback it means that scan\n\trates are very high. This is particularly true for direct\n\treclaim which is not calling writepage. The vmstat figures\n\timplied that much of this was busy work with PageReclaim pages\n\tmarked for immediate reclaim. This patch is a prototype that\n\tmoves these pages to their own LRU list.\n\nThis has been tested and other than 2 USB keys getting trashed,\nnothing horrible fell out. That said, I am a bit unhappy with the\nrescue logic in patch 11 but did not find a better way around it. It\ndoes significantly reduce scan rates and System CPU time indicating\nit is the right direction to take.\n\nWhat is of critical importance is that stalls due to compaction\nare massively reduced even though sync compaction was still\nallowed. Testing from people complaining about stalls copying to USBs\nwith THP enabled are particularly welcome.\n\nThe following tests all involve THP usage and USB keys in some\nway. Each test follows this type of pattern\n\n1. Read from some fast fast storage, be it raw device or file. Each time\n the copy finishes, start again until the test ends\n2. Write a large file to a filesystem on a USB stick. Each time the copy\n finishes, start again until the test ends\n3. When memory is low, start an alloc process that creates a mapping\n the size of physical memory to stress THP allocation. This is the\n \"real\" part of the test and the part that is meant to trigger\n stalls when THP is enabled. Copying continues in the background.\n4. Record the CPU usage and time to execute of the alloc process\n5. Record the number of THP allocs and fallbacks as well as the number of THP\n pages in use a the end of the test just before alloc exited\n6. Run the test 5 times to get an idea of variability\n7. Between each run, sync is run and caches dropped and the test\n waits until nr_dirty is a small number to avoid interference\n or caching between iterations that would skew the figures.\n\nThe individual tests were then\n\nwritebackCPDeviceBasevfat\n\tDisable THP, read from a raw device (sda), vfat on USB stick\nwritebackCPDeviceBaseext4\n\tDisable THP, read from a raw device (sda), ext4 on USB stick\nwritebackCPDevicevfat\n\tTHP enabled, read from a raw device (sda), vfat on USB stick\nwritebackCPDeviceext4\n\tTHP enabled, read from a raw device (sda), ext4 on USB stick\nwritebackCPFilevfat\n\tTHP enabled, read from a file on fast storage and USB, both vfat\nwritebackCPFileext4\n\tTHP enabled, read from a file on fast storage and USB, both ext4\n\nThe kernels tested were\n\n3.1\t\t3.1\nvanilla\t\t3.2-rc5\nfreemore\tPatches 1-10\nimmediate\tPatches 1-11\nandrea\t\tThe 8 patches Andrea posted as a basis of comparison\n\nThe results are very long unfortunately. I\u0027ll start with the case\nwhere we are not using THP at all\n\nwritebackCPDeviceBasevfat\n 3.1.0-vanilla rc5-vanilla freemore-v6r1 isolate-v6r1 andrea-v2r1\nSystem Time 1.28 ( 0.00%) 54.49 (-4143.46%) 48.63 (-3687.69%) 4.69 ( -265.11%) 51.88 (-3940.81%)\n+/- 0.06 ( 0.00%) 2.45 (-4305.55%) 4.75 (-8430.57%) 7.46 (-13282.76%) 4.76 (-8440.70%)\nUser Time 0.09 ( 0.00%) 0.05 ( 40.91%) 0.06 ( 29.55%) 0.07 ( 15.91%) 0.06 ( 27.27%)\n+/- 0.02 ( 0.00%) 0.01 ( 45.39%) 0.02 ( 25.07%) 0.00 ( 77.06%) 0.01 ( 52.24%)\nElapsed Time 110.27 ( 0.00%) 56.38 ( 48.87%) 49.95 ( 54.70%) 11.77 ( 89.33%) 53.43 ( 51.54%)\n+/- 7.33 ( 0.00%) 3.77 ( 48.61%) 4.94 ( 32.63%) 6.71 ( 8.50%) 4.76 ( 35.03%)\nTHP Active 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%)\n+/- 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%)\nFault Alloc 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%)\n+/- 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%)\nFault Fallback 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%)\n+/- 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%)\n\nThe THP figures are obviously all 0 because THP was enabled. The\nmain thing to watch is the elapsed times and how they compare to\ntimes when THP is enabled later. It\u0027s also important to note that\nelapsed time is improved by this series as System CPu time is much\nreduced.\n\nwritebackCPDevicevfat\n\n 3.1.0-vanilla rc5-vanilla freemore-v6r1 isolate-v6r1 andrea-v2r1\nSystem Time 1.22 ( 0.00%) 13.89 (-1040.72%) 46.40 (-3709.20%) 4.44 ( -264.37%) 47.37 (-3789.33%)\n+/- 0.06 ( 0.00%) 22.82 (-37635.56%) 3.84 (-6249.44%) 6.48 (-10618.92%) 6.60\n(-10818.53%)\nUser Time 0.06 ( 0.00%) 0.06 ( -6.90%) 0.05 ( 17.24%) 0.05 ( 13.79%) 0.04 ( 31.03%)\n+/- 0.01 ( 0.00%) 0.01 ( 33.33%) 0.01 ( 33.33%) 0.01 ( 39.14%) 0.01 ( 25.46%)\nElapsed Time 10445.54 ( 0.00%) 2249.92 ( 78.46%) 70.06 ( 99.33%) 16.59 ( 99.84%) 472.43 (\n95.48%)\n+/- 643.98 ( 0.00%) 811.62 ( -26.03%) 10.02 ( 98.44%) 7.03 ( 98.91%) 59.99 ( 90.68%)\nTHP Active 15.60 ( 0.00%) 35.20 ( 225.64%) 65.00 ( 416.67%) 70.80 ( 453.85%) 62.20 ( 398.72%)\n+/- 18.48 ( 0.00%) 51.29 ( 277.59%) 15.99 ( 86.52%) 37.91 ( 205.18%) 22.02 ( 119.18%)\nFault Alloc 121.80 ( 0.00%) 76.60 ( 62.89%) 155.40 ( 127.59%) 181.20 ( 148.77%) 286.60 ( 235.30%)\n+/- 73.51 ( 0.00%) 61.11 ( 83.12%) 34.89 ( 47.46%) 31.88 ( 43.36%) 68.13 ( 92.68%)\nFault Fallback 881.20 ( 0.00%) 926.60 ( -5.15%) 847.60 ( 3.81%) 822.00 ( 6.72%) 716.60 ( 18.68%)\n+/- 73.51 ( 0.00%) 61.26 ( 16.67%) 34.89 ( 52.54%) 31.65 ( 56.94%) 67.75 ( 7.84%)\nMMTests Statistics: duration\nUser/Sys Time Running Test (seconds) 3540.88 1945.37 716.04 64.97 1937.03\nTotal Elapsed Time (seconds) 52417.33 11425.90 501.02 230.95 2520.28\n\nThe first thing to note is the \"Elapsed Time\" for the vanilla kernels\nof 2249 seconds versus 56 with THP disabled which might explain the\nreports of USB stalls with THP enabled. Applying the patches brings\nperformance in line with THP-disabled performance while isolating\npages for immediate reclaim from the LRU cuts down System CPU time.\n\nThe \"Fault Alloc\" success rate figures are also improved. The vanilla\nkernel only managed to allocate 76.6 pages on average over the course\nof 5 iterations where as applying the series allocated 181.20 on\naverage albeit it is well within variance. It\u0027s worth noting that\napplies the series at least descreases the amount of variance which\nimplies an improvement.\n\nAndrea\u0027s series had a higher success rate for THP allocations but\nat a severe cost to elapsed time which is still better than vanilla\nbut still much worse than disabling THP altogether. One can bring my\nseries close to Andrea\u0027s by removing this check\n\n /*\n * If compaction is deferred for high-order allocations, it is because\n * sync compaction recently failed. In this is the case and the caller\n * has requested the system not be heavily disrupted, fail the\n * allocation now instead of entering direct reclaim\n */\n if (deferred_compaction \u0026\u0026 (gfp_mask \u0026 __GFP_NO_KSWAPD))\n goto nopage;\n\nI didn\u0027t include a patch that removed the above check because hurting\noverall performance to improve the THP figure is not what the average\nuser wants. It\u0027s something to consider though if someone really wants\nto maximise THP usage no matter what it does to the workload initially.\n\nThis is summary of vmstat figures from the same test.\n\n 3.1.0-vanilla rc5-vanilla freemore-v6r1 isolate-v6r1 andrea-v2r1\nPage Ins 3257266139 1111844061 17263623 10901575 161423219\nPage Outs 81054922 30364312 3626530 3657687 8753730\nSwap Ins 3294 2851 6560 4964 4592\nSwap Outs 390073 528094 620197 790912 698285\nDirect pages scanned 1077581700 3024951463 1764930052 115140570 5901188831\nKswapd pages scanned 34826043 7112868 2131265 1686942 1893966\nKswapd pages reclaimed 28950067 4911036 1246044 966475 1497726\nDirect pages reclaimed 805148398 280167837 3623473 2215044 40809360\nKswapd efficiency 83% 69% 58% 57% 79%\nKswapd velocity 664.399 622.521 4253.852 7304.360 751.490\nDirect efficiency 74% 9% 0% 1% 0%\nDirect velocity 20557.737 264745.137 3522673.849 498551.938 2341481.435\nPercentage direct scans 96% 99% 99% 98% 99%\nPage writes by reclaim 722646 529174 620319 791018 699198\nPage writes file 332573 1080 122 106 913\nPage writes anon 390073 528094 620197 790912 698285\nPage reclaim immediate 0 2552514720 1635858848 111281140 5478375032\nPage rescued immediate 0 0 0 87848 0\nSlabs scanned 23552 23552 9216 8192 9216\nDirect inode steals 231 0 0 0 0\nKswapd inode steals 0 0 0 0 0\nKswapd skipped wait 28076 786 0 61 6\nTHP fault alloc 609 383 753 906 1433\nTHP collapse alloc 12 6 0 0 6\nTHP splits 536 211 456 593 1136\nTHP fault fallback 4406 4633 4263 4110 3583\nTHP collapse fail 120 127 0 0 4\nCompaction stalls 1810 728 623 779 3200\nCompaction success 196 53 60 80 123\nCompaction failures 1614 675 563 699 3077\nCompaction pages moved 193158 53545 243185 333457 226688\nCompaction move failure 9952 9396 16424 23676 45070\n\nThe main things to look at are\n\n1. Page In/out figures are much reduced by the series.\n\n2. Direct page scanning is incredibly high (264745.137 pages scanned\n per second on the vanilla kernel) but isolating PageReclaim pages\n on their own list reduces the number of pages scanned significantly.\n\n3. The fact that \"Page rescued immediate\" is a positive number implies\n that we sometimes race removing pages from the LRU_IMMEDIATE list\n that need to be put back on a normal LRU but it happens only for\n 0.07% of the pages marked for immediate reclaim.\n\nwritebackCPDeviceext4\n 3.1.0-vanilla rc5-vanilla freemore-v6r1 isolate-v6r1 andrea-v2r1\nSystem Time 1.51 ( 0.00%) 1.77 ( -17.66%) 1.46 ( 2.92%) 1.15 ( 23.77%) 1.89 ( -25.63%)\n+/- 0.27 ( 0.00%) 0.67 ( -148.52%) 0.33 ( -22.76%) 0.30 ( -11.15%) 0.19 ( 30.16%)\nUser Time 0.03 ( 0.00%) 0.04 ( -37.50%) 0.05 ( -62.50%) 0.07 ( -112.50%) 0.04 ( -18.75%)\n+/- 0.01 ( 0.00%) 0.02 ( -146.64%) 0.02 ( -97.91%) 0.02 ( -75.59%) 0.02 ( -63.30%)\nElapsed Time 124.93 ( 0.00%) 114.49 ( 8.36%) 96.77 ( 22.55%) 27.48 ( 78.00%) 205.70 ( -64.65%)\n+/- 20.20 ( 0.00%) 74.39 ( -268.34%) 59.88 ( -196.48%) 7.72 ( 61.79%) 25.03 ( -23.95%)\nTHP Active 161.80 ( 0.00%) 83.60 ( 51.67%) 141.20 ( 87.27%) 84.60 ( 52.29%) 82.60 ( 51.05%)\n+/- 71.95 ( 0.00%) 43.80 ( 60.88%) 26.91 ( 37.40%) 59.02 ( 82.03%) 52.13 ( 72.45%)\nFault Alloc 471.40 ( 0.00%) 228.60 ( 48.49%) 282.20 ( 59.86%) 225.20 ( 47.77%) 388.40 ( 82.39%)\n+/- 88.07 ( 0.00%) 87.42 ( 99.26%) 73.79 ( 83.78%) 109.62 ( 124.47%) 82.62 ( 93.81%)\nFault Fallback 531.60 ( 0.00%) 774.60 ( -45.71%) 720.80 ( -35.59%) 777.80 ( -46.31%) 614.80 ( -15.65%)\n+/- 88.07 ( 0.00%) 87.26 ( 0.92%) 73.79 ( 16.22%) 109.62 ( -24.47%) 82.29 ( 6.56%)\nMMTests Statistics: duration\nUser/Sys Time Running Test (seconds) 50.22 33.76 30.65 24.14 128.45\nTotal Elapsed Time (seconds) 1113.73 1132.19 1029.45 759.49 1707.26\n\nSimilar test but the USB stick is using ext4 instead of vfat. As\next4 does not use writepage for migration, the large stalls due to\ncompaction when THP is enabled are not observed. Still, isolating\nPageReclaim pages on their own list helped completion time largely\nby reducing the number of pages scanned by direct reclaim although\ntime spend in congestion_wait could also be a factor.\n\nAgain, Andrea\u0027s series had far higher success rates for THP allocation\nat the cost of elapsed time. I didn\u0027t look too closely but a quick\nlook at the vmstat figures tells me kswapd reclaimed 8 times more pages\nthan the patch series and direct reclaim reclaimed roughly three times\nas many pages. It follows that if memory is aggressively reclaimed,\nthere will be more available for THP.\n\nwritebackCPFilevfat\n 3.1.0-vanilla rc5-vanilla freemore-v6r1 isolate-v6r1 andrea-v2r1\nSystem Time 1.76 ( 0.00%) 29.10 (-1555.52%) 46.01 (-2517.18%) 4.79 ( -172.35%) 54.89 (-3022.53%)\n+/- 0.14 ( 0.00%) 25.61 (-18185.17%) 2.15 (-1434.83%) 6.60 (-4610.03%) 9.75\n(-6863.76%)\nUser Time 0.05 ( 0.00%) 0.07 ( -45.83%) 0.05 ( -4.17%) 0.06 ( -29.17%) 0.06 ( -16.67%)\n+/- 0.02 ( 0.00%) 0.02 ( 20.11%) 0.02 ( -3.14%) 0.01 ( 31.58%) 0.01 ( 47.41%)\nElapsed Time 22520.79 ( 0.00%) 1082.85 ( 95.19%) 73.30 ( 99.67%) 32.43 ( 99.86%) 291.84 ( 98.70%)\n+/- 7277.23 ( 0.00%) 706.29 ( 90.29%) 19.05 ( 99.74%) 17.05 ( 99.77%) 125.55 ( 98.27%)\nTHP Active 83.80 ( 0.00%) 12.80 ( 15.27%) 15.60 ( 18.62%) 13.00 ( 15.51%) 0.80 ( 0.95%)\n+/- 66.81 ( 0.00%) 20.19 ( 30.22%) 5.92 ( 8.86%) 15.06 ( 22.54%) 1.17 ( 1.75%)\nFault Alloc 171.00 ( 0.00%) 67.80 ( 39.65%) 97.40 ( 56.96%) 125.60 ( 73.45%) 133.00 ( 77.78%)\n+/- 82.91 ( 0.00%) 30.69 ( 37.02%) 53.91 ( 65.02%) 55.05 ( 66.40%) 21.19 ( 25.56%)\nFault Fallback 832.00 ( 0.00%) 935.20 ( -12.40%) 906.00 ( -8.89%) 877.40 ( -5.46%) 870.20 ( -4.59%)\n+/- 82.91 ( 0.00%) 30.69 ( 62.98%) 54.01 ( 34.86%) 55.05 ( 33.60%) 20.91 ( 74.78%)\nMMTests Statistics: duration\nUser/Sys Time Running Test (seconds) 7229.81 928.42 704.52 80.68 1330.76\nTotal Elapsed Time (seconds) 112849.04 5618.69 571.11 360.54 1664.28\n\nIn this case, the test is reading/writing only from filesystems but as\nit\u0027s vfat, it\u0027s slow due to calling writepage during compaction. Little\nto observe really - the time to complete the test goes way down\nwith the series applied and THP allocation success rates go up in\ncomparison to 3.2-rc5. The success rates are lower than 3.1.0 but\nthe elapsed time for that kernel is abysmal so it is not really a\nsensible comparison.\n\nAs before, Andrea\u0027s series allocates more THPs at the cost of overall\nperformance.\n\nwritebackCPFileext4\n 3.1.0-vanilla rc5-vanilla freemore-v6r1 isolate-v6r1 andrea-v2r1\nSystem Time 1.51 ( 0.00%) 1.77 ( -17.66%) 1.46 ( 2.92%) 1.15 ( 23.77%) 1.89 ( -25.63%)\n+/- 0.27 ( 0.00%) 0.67 ( -148.52%) 0.33 ( -22.76%) 0.30 ( -11.15%) 0.19 ( 30.16%)\nUser Time 0.03 ( 0.00%) 0.04 ( -37.50%) 0.05 ( -62.50%) 0.07 ( -112.50%) 0.04 ( -18.75%)\n+/- 0.01 ( 0.00%) 0.02 ( -146.64%) 0.02 ( -97.91%) 0.02 ( -75.59%) 0.02 ( -63.30%)\nElapsed Time 124.93 ( 0.00%) 114.49 ( 8.36%) 96.77 ( 22.55%) 27.48 ( 78.00%) 205.70 ( -64.65%)\n+/- 20.20 ( 0.00%) 74.39 ( -268.34%) 59.88 ( -196.48%) 7.72 ( 61.79%) 25.03 ( -23.95%)\nTHP Active 161.80 ( 0.00%) 83.60 ( 51.67%) 141.20 ( 87.27%) 84.60 ( 52.29%) 82.60 ( 51.05%)\n+/- 71.95 ( 0.00%) 43.80 ( 60.88%) 26.91 ( 37.40%) 59.02 ( 82.03%) 52.13 ( 72.45%)\nFault Alloc 471.40 ( 0.00%) 228.60 ( 48.49%) 282.20 ( 59.86%) 225.20 ( 47.77%) 388.40 ( 82.39%)\n+/- 88.07 ( 0.00%) 87.42 ( 99.26%) 73.79 ( 83.78%) 109.62 ( 124.47%) 82.62 ( 93.81%)\nFault Fallback 531.60 ( 0.00%) 774.60 ( -45.71%) 720.80 ( -35.59%) 777.80 ( -46.31%) 614.80 ( -15.65%)\n+/- 88.07 ( 0.00%) 87.26 ( 0.92%) 73.79 ( 16.22%) 109.62 ( -24.47%) 82.29 ( 6.56%)\nMMTests Statistics: duration\nUser/Sys Time Running Test (seconds) 50.22 33.76 30.65 24.14 128.45\nTotal Elapsed Time (seconds) 1113.73 1132.19 1029.45 759.49 1707.26\n\nSame type of story - elapsed times go down. In this case, allocation\nsuccess rates are roughtly the same. As before, Andrea\u0027s has higher\nsuccess rates but takes a lot longer.\n\nOverall the series does reduce latencies and while the tests are\ninherency racy as alloc competes with the cp processes, the variability\nwas included. The THP allocation rates are not as high as they could\nbe but that is because we would have to be more aggressive about\nreclaim and compaction impacting overall performance.\n\nThis patch:\n\nCommit 39deaf85 (\"mm: compaction: make isolate_lru_page() filter-aware\")\nnoted that compaction does not migrate dirty or writeback pages and that\nis was meaningless to pick the page and re-add it to the LRU list.\n\nWhat was missed during review is that asynchronous migration moves dirty\npages if their -\u003emigratepage callback is migrate_page() because these can\nbe moved without blocking. This potentially impacted hugepage allocation\nsuccess rates by a factor depending on how many dirty pages are in the\nsystem.\n\nThis patch partially reverts 39deaf85 to allow migration to isolate dirty\npages again. This increases how much compaction disrupts the LRU but that\nis addressed later in the series.\n\nSigned-off-by: Mel Gorman \u003cmgorman@suse.de\u003e\nReviewed-by: Andrea Arcangeli \u003caarcange@redhat.com\u003e\nReviewed-by: Rik van Riel \u003criel@redhat.com\u003e\nReviewed-by: Minchan Kim \u003cminchan.kim@gmail.com\u003e\nCc: Dave Jones \u003cdavej@redhat.com\u003e\nCc: Jan Kara \u003cjack@suse.cz\u003e\nCc: Andy Isaacson \u003cadi@hexapodia.org\u003e\nCc: Nai Xia \u003cnai.xia@gmail.com\u003e\nCc: Johannes Weiner \u003cjweiner@redhat.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n", "tree_diff": [ { "type": "modify", "old_id": "e6670c34eb4950b8953eeedbe02fe52f29ec84bf", "old_mode": 33188, "old_path": "mm/compaction.c", "new_id": "396ea2b47f7e9b94003b328246b80fcc19e55511", "new_mode": 33188, "new_path": "mm/compaction.c" } ] }