From: Jesper Dangaard Brouer <brouer@redhat.com> To: Mel Gorman <mgorman@techsingularity.net> Cc: Andrew Morton <akpm@linux-foundation.org>, Vlastimil Babka <vbabka@suse.cz>, Linux-MM <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>, brouer@redhat.com, "netdev@vger.kernel.org" <netdev@vger.kernel.org> Subject: Re: [PATCH 00/28] Optimise page alloc/free fast paths v3 Date: Fri, 15 Apr 2016 14:44:02 +0200 [thread overview] Message-ID: <20160415144402.5fbe7a1e@redhat.com> (raw) In-Reply-To: <1460710760-32601-1-git-send-email-mgorman@techsingularity.net> On Fri, 15 Apr 2016 09:58:52 +0100 Mel Gorman <mgorman@techsingularity.net> wrote: > There were no further responses to the last series but I kept going and > added a few more small bits. Most are basic micro-optimisations. The last > two patches weaken debugging checks to improve performance at the cost of > delayed detection of some use-after-free and memory corruption bugs. If > they make people uncomfortable, they can be dropped and the rest of the > series stands on its own. > > Changelog since v2 > o Add more micro-optimisations > o Weak debugging checks in favor of speed > [...] > > The overall impact on a page allocator microbenchmark for a range of orders I also micro benchmarked this patchset. Avail via Mel Gorman's kernel tree: http://git.kernel.org/cgit/linux/kernel/git/mel/linux.git tested branch mm-vmscan-node-lru-v5r9 which also contain the node-lru series. Tool: https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/bench/page_bench01.c Run as: modprobe page_bench01; rmmod page_bench01 ; dmesg | tail -n40 | grep 'alloc_pages order' Results kernel 4.6.0-rc1 : alloc_pages order:0(4096B/x1) 272 cycles per-4096B 272 cycles alloc_pages order:1(8192B/x2) 395 cycles per-4096B 197 cycles alloc_pages order:2(16384B/x4) 433 cycles per-4096B 108 cycles alloc_pages order:3(32768B/x8) 503 cycles per-4096B 62 cycles alloc_pages order:4(65536B/x16) 682 cycles per-4096B 42 cycles alloc_pages order:5(131072B/x32) 910 cycles per-4096B 28 cycles alloc_pages order:6(262144B/x64) 1384 cycles per-4096B 21 cycles alloc_pages order:7(524288B/x128) 2335 cycles per-4096B 18 cycles alloc_pages order:8(1048576B/x256) 4108 cycles per-4096B 16 cycles alloc_pages order:9(2097152B/x512) 8398 cycles per-4096B 16 cycles After Mel Gorman's optimizations, results from mm-vmscan-node-lru-v5r:: alloc_pages order:0(4096B/x1) 231 cycles per-4096B 231 cycles alloc_pages order:1(8192B/x2) 351 cycles per-4096B 175 cycles alloc_pages order:2(16384B/x4) 357 cycles per-4096B 89 cycles alloc_pages order:3(32768B/x8) 397 cycles per-4096B 49 cycles alloc_pages order:4(65536B/x16) 481 cycles per-4096B 30 cycles alloc_pages order:5(131072B/x32) 652 cycles per-4096B 20 cycles alloc_pages order:6(262144B/x64) 1054 cycles per-4096B 16 cycles alloc_pages order:7(524288B/x128) 1852 cycles per-4096B 14 cycles alloc_pages order:8(1048576B/x256) 3156 cycles per-4096B 12 cycles alloc_pages order:9(2097152B/x512) 6790 cycles per-4096B 13 cycles I've also started doing some parallel concurrency testing workloads[1] [1] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/bench/page_bench03.c Order-0 pages scale nicely: Results kernel 4.6.0-rc1 : Parallel-CPUs:1 page order:0(4096B/x1) ave 274 cycles per-4096B 274 cycles Parallel-CPUs:2 page order:0(4096B/x1) ave 283 cycles per-4096B 283 cycles Parallel-CPUs:3 page order:0(4096B/x1) ave 284 cycles per-4096B 284 cycles Parallel-CPUs:4 page order:0(4096B/x1) ave 288 cycles per-4096B 288 cycles Parallel-CPUs:5 page order:0(4096B/x1) ave 417 cycles per-4096B 417 cycles Parallel-CPUs:6 page order:0(4096B/x1) ave 503 cycles per-4096B 503 cycles Parallel-CPUs:7 page order:0(4096B/x1) ave 567 cycles per-4096B 567 cycles Parallel-CPUs:8 page order:0(4096B/x1) ave 620 cycles per-4096B 620 cycles And even better with you changes! :-))) This is great work! Results from mm-vmscan-node-lru-v5r: Parallel-CPUs:1 page order:0(4096B/x1) ave 246 cycles per-4096B 246 cycles Parallel-CPUs:2 page order:0(4096B/x1) ave 251 cycles per-4096B 251 cycles Parallel-CPUs:3 page order:0(4096B/x1) ave 254 cycles per-4096B 254 cycles Parallel-CPUs:4 page order:0(4096B/x1) ave 258 cycles per-4096B 258 cycles Parallel-CPUs:5 page order:0(4096B/x1) ave 313 cycles per-4096B 313 cycles Parallel-CPUs:6 page order:0(4096B/x1) ave 369 cycles per-4096B 369 cycles Parallel-CPUs:7 page order:0(4096B/x1) ave 379 cycles per-4096B 379 cycles Parallel-CPUs:8 page order:0(4096B/x1) ave 399 cycles per-4096B 399 cycles It does not seem that higher order page scale... and your patches does not change this pattern. Example order-3 pages, which is often used in the network stack: Results kernel 4.6.0-rc1 :: Parallel-CPUs:1 page order:3(32768B/x8) ave 524 cycles per-4096B 65 cycles Parallel-CPUs:2 page order:3(32768B/x8) ave 2131 cycles per-4096B 266 cycles Parallel-CPUs:3 page order:3(32768B/x8) ave 3885 cycles per-4096B 485 cycles Parallel-CPUs:4 page order:3(32768B/x8) ave 4520 cycles per-4096B 565 cycles Parallel-CPUs:5 page order:3(32768B/x8) ave 5604 cycles per-4096B 700 cycles Parallel-CPUs:6 page order:3(32768B/x8) ave 7125 cycles per-4096B 890 cycles Parallel-CPUs:7 page order:3(32768B/x8) ave 7883 cycles per-4096B 985 cycles Parallel-CPUs:8 page order:3(32768B/x8) ave 9364 cycles per-4096B 1170 cycles Results from mm-vmscan-node-lru-v5r: Parallel-CPUs:1 page order:3(32768B/x8) ave 421 cycles per-4096B 52 cycles Parallel-CPUs:2 page order:3(32768B/x8) ave 2236 cycles per-4096B 279 cycles Parallel-CPUs:3 page order:3(32768B/x8) ave 3408 cycles per-4096B 426 cycles Parallel-CPUs:4 page order:3(32768B/x8) ave 4687 cycles per-4096B 585 cycles Parallel-CPUs:5 page order:3(32768B/x8) ave 5972 cycles per-4096B 746 cycles Parallel-CPUs:6 page order:3(32768B/x8) ave 7349 cycles per-4096B 918 cycles Parallel-CPUs:7 page order:3(32768B/x8) ave 8436 cycles per-4096B 1054 cycles Parallel-CPUs:8 page order:3(32768B/x8) ave 9589 cycles per-4096B 1198 cycles -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/bench/page_bench03.c for ORDER in $(seq 0 5) ; do \ for X in $(seq 1 8) ; do \ modprobe page_bench03 page_order=$ORDER parallel_cpus=$X run_flags=$((2#100)); \ rmmod page_bench03 ; dmesg | tail -n 3 | grep Parallel-CPUs ; \ done; \ done
WARNING: multiple messages have this Message-ID (diff)
From: Jesper Dangaard Brouer <brouer@redhat.com> To: Mel Gorman <mgorman@techsingularity.net> Cc: Andrew Morton <akpm@linux-foundation.org>, Vlastimil Babka <vbabka@suse.cz>, Linux-MM <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>, brouer@redhat.com, "netdev@vger.kernel.org" <netdev@vger.kernel.org> Subject: Re: [PATCH 00/28] Optimise page alloc/free fast paths v3 Date: Fri, 15 Apr 2016 14:44:02 +0200 [thread overview] Message-ID: <20160415144402.5fbe7a1e@redhat.com> (raw) In-Reply-To: <1460710760-32601-1-git-send-email-mgorman@techsingularity.net> On Fri, 15 Apr 2016 09:58:52 +0100 Mel Gorman <mgorman@techsingularity.net> wrote: > There were no further responses to the last series but I kept going and > added a few more small bits. Most are basic micro-optimisations. The last > two patches weaken debugging checks to improve performance at the cost of > delayed detection of some use-after-free and memory corruption bugs. If > they make people uncomfortable, they can be dropped and the rest of the > series stands on its own. > > Changelog since v2 > o Add more micro-optimisations > o Weak debugging checks in favor of speed > [...] > > The overall impact on a page allocator microbenchmark for a range of orders I also micro benchmarked this patchset. Avail via Mel Gorman's kernel tree: http://git.kernel.org/cgit/linux/kernel/git/mel/linux.git tested branch mm-vmscan-node-lru-v5r9 which also contain the node-lru series. Tool: https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/bench/page_bench01.c Run as: modprobe page_bench01; rmmod page_bench01 ; dmesg | tail -n40 | grep 'alloc_pages order' Results kernel 4.6.0-rc1 : alloc_pages order:0(4096B/x1) 272 cycles per-4096B 272 cycles alloc_pages order:1(8192B/x2) 395 cycles per-4096B 197 cycles alloc_pages order:2(16384B/x4) 433 cycles per-4096B 108 cycles alloc_pages order:3(32768B/x8) 503 cycles per-4096B 62 cycles alloc_pages order:4(65536B/x16) 682 cycles per-4096B 42 cycles alloc_pages order:5(131072B/x32) 910 cycles per-4096B 28 cycles alloc_pages order:6(262144B/x64) 1384 cycles per-4096B 21 cycles alloc_pages order:7(524288B/x128) 2335 cycles per-4096B 18 cycles alloc_pages order:8(1048576B/x256) 4108 cycles per-4096B 16 cycles alloc_pages order:9(2097152B/x512) 8398 cycles per-4096B 16 cycles After Mel Gorman's optimizations, results from mm-vmscan-node-lru-v5r:: alloc_pages order:0(4096B/x1) 231 cycles per-4096B 231 cycles alloc_pages order:1(8192B/x2) 351 cycles per-4096B 175 cycles alloc_pages order:2(16384B/x4) 357 cycles per-4096B 89 cycles alloc_pages order:3(32768B/x8) 397 cycles per-4096B 49 cycles alloc_pages order:4(65536B/x16) 481 cycles per-4096B 30 cycles alloc_pages order:5(131072B/x32) 652 cycles per-4096B 20 cycles alloc_pages order:6(262144B/x64) 1054 cycles per-4096B 16 cycles alloc_pages order:7(524288B/x128) 1852 cycles per-4096B 14 cycles alloc_pages order:8(1048576B/x256) 3156 cycles per-4096B 12 cycles alloc_pages order:9(2097152B/x512) 6790 cycles per-4096B 13 cycles I've also started doing some parallel concurrency testing workloads[1] [1] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/bench/page_bench03.c Order-0 pages scale nicely: Results kernel 4.6.0-rc1 : Parallel-CPUs:1 page order:0(4096B/x1) ave 274 cycles per-4096B 274 cycles Parallel-CPUs:2 page order:0(4096B/x1) ave 283 cycles per-4096B 283 cycles Parallel-CPUs:3 page order:0(4096B/x1) ave 284 cycles per-4096B 284 cycles Parallel-CPUs:4 page order:0(4096B/x1) ave 288 cycles per-4096B 288 cycles Parallel-CPUs:5 page order:0(4096B/x1) ave 417 cycles per-4096B 417 cycles Parallel-CPUs:6 page order:0(4096B/x1) ave 503 cycles per-4096B 503 cycles Parallel-CPUs:7 page order:0(4096B/x1) ave 567 cycles per-4096B 567 cycles Parallel-CPUs:8 page order:0(4096B/x1) ave 620 cycles per-4096B 620 cycles And even better with you changes! :-))) This is great work! Results from mm-vmscan-node-lru-v5r: Parallel-CPUs:1 page order:0(4096B/x1) ave 246 cycles per-4096B 246 cycles Parallel-CPUs:2 page order:0(4096B/x1) ave 251 cycles per-4096B 251 cycles Parallel-CPUs:3 page order:0(4096B/x1) ave 254 cycles per-4096B 254 cycles Parallel-CPUs:4 page order:0(4096B/x1) ave 258 cycles per-4096B 258 cycles Parallel-CPUs:5 page order:0(4096B/x1) ave 313 cycles per-4096B 313 cycles Parallel-CPUs:6 page order:0(4096B/x1) ave 369 cycles per-4096B 369 cycles Parallel-CPUs:7 page order:0(4096B/x1) ave 379 cycles per-4096B 379 cycles Parallel-CPUs:8 page order:0(4096B/x1) ave 399 cycles per-4096B 399 cycles It does not seem that higher order page scale... and your patches does not change this pattern. Example order-3 pages, which is often used in the network stack: Results kernel 4.6.0-rc1 :: Parallel-CPUs:1 page order:3(32768B/x8) ave 524 cycles per-4096B 65 cycles Parallel-CPUs:2 page order:3(32768B/x8) ave 2131 cycles per-4096B 266 cycles Parallel-CPUs:3 page order:3(32768B/x8) ave 3885 cycles per-4096B 485 cycles Parallel-CPUs:4 page order:3(32768B/x8) ave 4520 cycles per-4096B 565 cycles Parallel-CPUs:5 page order:3(32768B/x8) ave 5604 cycles per-4096B 700 cycles Parallel-CPUs:6 page order:3(32768B/x8) ave 7125 cycles per-4096B 890 cycles Parallel-CPUs:7 page order:3(32768B/x8) ave 7883 cycles per-4096B 985 cycles Parallel-CPUs:8 page order:3(32768B/x8) ave 9364 cycles per-4096B 1170 cycles Results from mm-vmscan-node-lru-v5r: Parallel-CPUs:1 page order:3(32768B/x8) ave 421 cycles per-4096B 52 cycles Parallel-CPUs:2 page order:3(32768B/x8) ave 2236 cycles per-4096B 279 cycles Parallel-CPUs:3 page order:3(32768B/x8) ave 3408 cycles per-4096B 426 cycles Parallel-CPUs:4 page order:3(32768B/x8) ave 4687 cycles per-4096B 585 cycles Parallel-CPUs:5 page order:3(32768B/x8) ave 5972 cycles per-4096B 746 cycles Parallel-CPUs:6 page order:3(32768B/x8) ave 7349 cycles per-4096B 918 cycles Parallel-CPUs:7 page order:3(32768B/x8) ave 8436 cycles per-4096B 1054 cycles Parallel-CPUs:8 page order:3(32768B/x8) ave 9589 cycles per-4096B 1198 cycles -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/bench/page_bench03.c for ORDER in $(seq 0 5) ; do \ for X in $(seq 1 8) ; do \ modprobe page_bench03 page_order=$ORDER parallel_cpus=$X run_flags=$((2#100)); \ rmmod page_bench03 ; dmesg | tail -n 3 | grep Parallel-CPUs ; \ done; \ done -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-04-15 12:44 UTC|newest] Thread overview: 160+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-15 8:58 [PATCH 00/28] Optimise page alloc/free fast paths v3 Mel Gorman 2016-04-15 8:58 ` Mel Gorman 2016-04-15 8:58 ` [PATCH 01/28] mm, page_alloc: Only check PageCompound for high-order pages Mel Gorman 2016-04-15 8:58 ` Mel Gorman 2016-04-25 9:33 ` Vlastimil Babka 2016-04-25 9:33 ` Vlastimil Babka 2016-04-26 10:33 ` Mel Gorman 2016-04-26 10:33 ` Mel Gorman 2016-04-26 11:20 ` Vlastimil Babka 2016-04-26 11:20 ` Vlastimil Babka 2016-04-15 8:58 ` [PATCH 02/28] mm, page_alloc: Use new PageAnonHead helper in the free page fast path Mel Gorman 2016-04-15 8:58 ` Mel Gorman 2016-04-25 9:56 ` Vlastimil Babka 2016-04-25 9:56 ` Vlastimil Babka 2016-04-15 8:58 ` [PATCH 03/28] mm, page_alloc: Reduce branches in zone_statistics Mel Gorman 2016-04-15 8:58 ` Mel Gorman 2016-04-25 11:15 ` Vlastimil Babka 2016-04-25 11:15 ` Vlastimil Babka 2016-04-15 8:58 ` [PATCH 04/28] mm, page_alloc: Inline zone_statistics Mel Gorman 2016-04-15 8:58 ` Mel Gorman 2016-04-25 11:17 ` Vlastimil Babka 2016-04-25 11:17 ` Vlastimil Babka 2016-04-15 8:58 ` [PATCH 05/28] mm, page_alloc: Inline the fast path of the zonelist iterator Mel Gorman 2016-04-15 8:58 ` Mel Gorman 2016-04-25 14:50 ` Vlastimil Babka 2016-04-25 14:50 ` Vlastimil Babka 2016-04-26 10:30 ` Mel Gorman 2016-04-26 10:30 ` Mel Gorman 2016-04-26 11:05 ` Vlastimil Babka 2016-04-26 11:05 ` Vlastimil Babka 2016-04-15 8:58 ` [PATCH 06/28] mm, page_alloc: Use __dec_zone_state for order-0 page allocation Mel Gorman 2016-04-15 8:58 ` Mel Gorman 2016-04-26 11:25 ` Vlastimil Babka 2016-04-26 11:25 ` Vlastimil Babka 2016-04-15 8:58 ` [PATCH 07/28] mm, page_alloc: Avoid unnecessary zone lookups during pageblock operations Mel Gorman 2016-04-15 8:58 ` Mel Gorman 2016-04-26 11:29 ` Vlastimil Babka 2016-04-26 11:29 ` Vlastimil Babka 2016-04-15 8:59 ` [PATCH 08/28] mm, page_alloc: Convert alloc_flags to unsigned Mel Gorman 2016-04-15 8:59 ` Mel Gorman 2016-04-26 11:31 ` Vlastimil Babka 2016-04-26 11:31 ` Vlastimil Babka 2016-04-15 8:59 ` [PATCH 09/28] mm, page_alloc: Convert nr_fair_skipped to bool Mel Gorman 2016-04-15 8:59 ` Mel Gorman 2016-04-26 11:37 ` Vlastimil Babka 2016-04-26 11:37 ` Vlastimil Babka 2016-04-15 8:59 ` [PATCH 10/28] mm, page_alloc: Remove unnecessary local variable in get_page_from_freelist Mel Gorman 2016-04-15 8:59 ` Mel Gorman 2016-04-26 11:38 ` Vlastimil Babka 2016-04-26 11:38 ` Vlastimil Babka 2016-04-15 8:59 ` [PATCH 11/28] mm, page_alloc: Remove unnecessary initialisation " Mel Gorman 2016-04-15 8:59 ` Mel Gorman 2016-04-26 11:39 ` Vlastimil Babka 2016-04-26 11:39 ` Vlastimil Babka 2016-04-15 9:07 ` [PATCH 13/28] mm, page_alloc: Remove redundant check for empty zonelist Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-15 9:07 ` [PATCH 14/28] mm, page_alloc: Simplify last cpupid reset Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-26 13:30 ` Vlastimil Babka 2016-04-26 13:30 ` Vlastimil Babka 2016-04-15 9:07 ` [PATCH 15/28] mm, page_alloc: Move might_sleep_if check to the allocator slowpath Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-26 13:41 ` Vlastimil Babka 2016-04-26 13:41 ` Vlastimil Babka 2016-04-26 14:50 ` Mel Gorman 2016-04-26 14:50 ` Mel Gorman 2016-04-26 15:16 ` Vlastimil Babka 2016-04-26 15:16 ` Vlastimil Babka 2016-04-26 16:29 ` Mel Gorman 2016-04-26 16:29 ` Mel Gorman 2016-04-15 9:07 ` [PATCH 16/28] mm, page_alloc: Move __GFP_HARDWALL modifications out of the fastpath Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-26 14:13 ` Vlastimil Babka 2016-04-26 14:13 ` Vlastimil Babka 2016-04-15 9:07 ` [PATCH 17/28] mm, page_alloc: Check once if a zone has isolated pageblocks Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-26 14:27 ` Vlastimil Babka 2016-04-26 14:27 ` Vlastimil Babka 2016-04-15 9:07 ` [PATCH 18/28] mm, page_alloc: Shorten the page allocator fast path Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-26 15:23 ` Vlastimil Babka 2016-04-26 15:23 ` Vlastimil Babka 2016-04-15 9:07 ` [PATCH 19/28] mm, page_alloc: Reduce cost of fair zone allocation policy retry Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-26 17:24 ` Vlastimil Babka 2016-04-26 17:24 ` Vlastimil Babka 2016-04-15 9:07 ` [PATCH 20/28] mm, page_alloc: Shortcut watermark checks for order-0 pages Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-26 17:32 ` Vlastimil Babka 2016-04-26 17:32 ` Vlastimil Babka 2016-04-15 9:07 ` [PATCH 21/28] mm, page_alloc: Avoid looking up the first zone in a zonelist twice Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-26 17:46 ` Vlastimil Babka 2016-04-26 17:46 ` Vlastimil Babka 2016-04-15 9:07 ` [PATCH 22/28] mm, page_alloc: Remove field from alloc_context Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-15 9:07 ` [PATCH 23/28] mm, page_alloc: Check multiple page fields with a single branch Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-26 18:41 ` Vlastimil Babka 2016-04-26 18:41 ` Vlastimil Babka 2016-04-27 10:07 ` Mel Gorman 2016-04-27 10:07 ` Mel Gorman 2016-04-15 9:07 ` [PATCH 24/28] mm, page_alloc: Remove unnecessary variable from free_pcppages_bulk Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-26 18:43 ` Vlastimil Babka 2016-04-26 18:43 ` Vlastimil Babka 2016-04-15 9:07 ` [PATCH 25/28] mm, page_alloc: Inline pageblock lookup in page free fast paths Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-26 19:10 ` Vlastimil Babka 2016-04-26 19:10 ` Vlastimil Babka 2016-04-15 9:07 ` [PATCH 26/28] cpuset: use static key better and convert to new API Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-26 19:49 ` Vlastimil Babka 2016-04-26 19:49 ` Vlastimil Babka 2016-04-15 9:07 ` [PATCH 27/28] mm, page_alloc: Defer debugging checks of freed pages until a PCP drain Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-27 11:59 ` Vlastimil Babka 2016-04-27 11:59 ` Vlastimil Babka 2016-04-27 12:01 ` [PATCH 1/3] mm, page_alloc: un-inline the bad part of free_pages_check Vlastimil Babka 2016-04-27 12:01 ` Vlastimil Babka 2016-04-27 12:01 ` [PATCH 2/3] mm, page_alloc: pull out side effects from free_pages_check Vlastimil Babka 2016-04-27 12:01 ` Vlastimil Babka 2016-04-27 12:41 ` Mel Gorman 2016-04-27 12:41 ` Mel Gorman 2016-04-27 13:00 ` Vlastimil Babka 2016-04-27 13:00 ` Vlastimil Babka 2016-04-27 12:01 ` [PATCH 3/3] mm, page_alloc: don't duplicate code in free_pcp_prepare Vlastimil Babka 2016-04-27 12:01 ` Vlastimil Babka 2016-04-27 12:37 ` [PATCH 1/3] mm, page_alloc: un-inline the bad part of free_pages_check Mel Gorman 2016-04-27 12:37 ` Mel Gorman 2016-04-27 12:53 ` Vlastimil Babka 2016-04-27 12:53 ` Vlastimil Babka 2016-04-15 9:07 ` [PATCH 28/28] mm, page_alloc: Defer debugging checks of pages allocated from the PCP Mel Gorman 2016-04-15 9:07 ` Mel Gorman 2016-04-27 14:06 ` Vlastimil Babka 2016-04-27 14:06 ` Vlastimil Babka 2016-04-27 15:31 ` Mel Gorman 2016-04-27 15:31 ` Mel Gorman 2016-05-17 6:41 ` Naoya Horiguchi 2016-05-17 6:41 ` Naoya Horiguchi 2016-05-18 7:51 ` Vlastimil Babka 2016-05-18 7:51 ` Vlastimil Babka 2016-05-18 7:55 ` Vlastimil Babka 2016-05-18 7:55 ` Vlastimil Babka 2016-05-18 8:49 ` Mel Gorman 2016-05-18 8:49 ` Mel Gorman 2016-04-26 12:04 ` [PATCH 13/28] mm, page_alloc: Remove redundant check for empty zonelist Vlastimil Babka 2016-04-26 12:04 ` Vlastimil Babka 2016-04-26 13:00 ` Mel Gorman 2016-04-26 13:00 ` Mel Gorman 2016-04-26 19:11 ` Andrew Morton 2016-04-26 19:11 ` Andrew Morton 2016-04-15 12:44 ` Jesper Dangaard Brouer [this message] 2016-04-15 12:44 ` [PATCH 00/28] Optimise page alloc/free fast paths v3 Jesper Dangaard Brouer 2016-04-15 13:08 ` Mel Gorman 2016-04-15 13:08 ` Mel Gorman 2016-04-16 7:21 ` [PATCH 12/28] mm, page_alloc: Remove unnecessary initialisation from __alloc_pages_nodemask() Mel Gorman 2016-04-16 7:21 ` Mel Gorman 2016-04-26 11:41 ` Vlastimil Babka 2016-04-26 11:41 ` Vlastimil Babka
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160415144402.5fbe7a1e@redhat.com \ --to=brouer@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@techsingularity.net \ --cc=netdev@vger.kernel.org \ --cc=vbabka@suse.cz \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.