On Mon, Mar 03, 2014 at 12:02:00PM +0100, Vlastimil Babka wrote: > On 02/14/2014 07:53 AM, Joonsoo Kim wrote: > > changes for v2 > > o include more experiment data in cover letter > > o deal with vlastimil's comments mostly about commit description on 4/5 > > > > This patchset is related to the compaction. > > > > patch 1 fixes contrary implementation of the purpose of compaction. > > patch 2~4 are for optimization. > > patch 5 is just for clean-up. > > > > I tested this patchset with stress-highalloc benchmark on Mel's mmtest > > and cannot find any regression in terms of success rate. And I find > > much reduced(9%) elapsed time. > > > > Below is the average result of 10 runs on my 4GB quad core system. > > > > compaction-base+ is based on 3.13.0 with Vlastimil's recent fixes. > > compaction-fix+ has this patch series on top of compaction-base+. > > > > Thanks. > > > > > > stress-highalloc > > 3.13.0 3.13.0 > > compaction-base+ compaction-fix+ > > Success 1 14.10 15.00 > > Success 2 20.20 20.00 > > Success 3 68.30 73.40 > > > > > > 3.13.0 3.13.0 > > compaction-base+ compaction-fix+ > > User 3486.02 3437.13 > > System 757.92 741.15 > > Elapsed 1638.52 1488.32 > > > > 3.13.0 3.13.0 > > compaction-base+ compaction-fix+ > > Minor Faults 172591561 167116621 > > Major Faults 984 859 > > Swap Ins 743 653 > > Swap Outs 3657 3535 > > Direct pages scanned 129742 127344 > > Kswapd pages scanned 1852277 1817825 > > Kswapd pages reclaimed 1838000 1804212 > > Direct pages reclaimed 129719 127327 > > Kswapd efficiency 98% 98% > > Kswapd velocity 1130.066 1221.296 > > Direct efficiency 99% 99% > > Direct velocity 79.367 85.585 > > Percentage direct scans 6% 6% > > Zone normal velocity 231.829 246.097 > > Zone dma32 velocity 972.589 1055.158 > > Zone dma velocity 5.015 5.626 > > Page writes by reclaim 6287 6534 > > Page writes file 2630 2999 > > Page writes anon 3657 3535 > > Page reclaim immediate 2187 2080 > > Sector Reads 2917808 2877336 > > Sector Writes 11477891 11206722 > > Page rescued immediate 0 0 > > Slabs scanned 2214118 2168524 > > Direct inode steals 12181 9788 > > Kswapd inode steals 144830 132109 > > Kswapd skipped wait 0 0 > > THP fault alloc 0 0 > > THP collapse alloc 0 0 > > THP splits 0 0 > > THP fault fallback 0 0 > > THP collapse fail 0 0 > > Compaction stalls 738 714 > > Compaction success 194 207 > > Compaction failures 543 507 > > Page migrate success 1806083 1464014 > > Page migrate failure 0 0 > > Compaction pages isolated 3873329 3162974 > > Compaction migrate scanned 74594862 59874420 > > Compaction free scanned 125888854 110868637 > > Compaction cost 2469 1998 > > FWIW, I've let a machine run the series with individual patches applied > on 3.13 with my compaction patches, so 6 is the end of my series and 7-11 > yours: > The average is of 10 runs (in case you wonder how that's done, the success > rates are > calculated with a new R support that's pending Mel's merge; system time and > vmstats > are currently a hack, but I hope to add R support for them as well, and maybe > publish > to github or something if there's interest).
Good! I have an interest on it. > > Interestingly, you have a much lower success rate and also much lower > compaction cost > and, well, even the benchmark times. Wonder what difference in config or hw > causes this. > You seem to have THP disabled, I enabled, but that would be weird to cause > this. My 10 runs are continuous 10 runs without reboot. It makes compaction success rate decline on every trial and therefore average result is so low than yours. I heard that you did 10 runs because of large stdev, so I thought that continuous 10 runs also can makes the result reliable. Therefore I decided this method although it is not proper method to get the average. I had to notify about it. If it confuses you, sorry about that. Anyway, noticeable point of continuous 10 runs is that success rate decrease continuously and significantly. I attach the rate of success 3 on every trial on below. Base % Success: 80 % Success: 60 % Success: 76 % Success: 74 % Success: 70 % Success: 68 % Success: 66 % Success: 65 % Success: 63 % Success: 61 Applied with my patches % Success: 81 % Success: 78 % Success: 75 % Success: 74 % Success: 71 % Success: 72 % Success: 73 % Success: 70 % Success: 70 % Success: 70 It means that memory is fragmented continously. I didn't dig into this problem, but it would be good subject to investigate. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
