Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1624127
| From | Mel Gorman <mgorman@techsingularity.net> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] Revert "mm, page_alloc: only use per-cpu allocator for irq-safe requests" |
| Date | 2017-04-15 22:00 +0200 |
| Message-ID | <twC1r-2no-1@gated-at.bofh.it> (permalink) |
| References | <twxl7-7NQ-7@gated-at.bofh.it> <twByp-2cM-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Sat, Apr 15, 2017 at 09:28:33PM +0200, Jesper Dangaard Brouer wrote: > On Sat, 15 Apr 2017 15:53:50 +0100 > Mel Gorman <mgorman@techsingularity.net> wrote: > > > This reverts commit 374ad05ab64d696303cec5cc8ec3a65d457b7b1c. While the > > patch worked great for userspace allocations, the fact that softirq loses > > the per-cpu allocator caused problems. It needs to be redone taking into > > account that a separate list is needed for hard/soft IRQs or alternatively > > find a cheap way of detecting reentry due to an interrupt. Both are possible > > but sufficiently tricky that it shouldn't be rushed. Jesper had one method > > for allowing softirqs but reported that the cost was high enough that it > > performed similarly to a plain revert. His figures for netperf TCP_STREAM > > were as follows > > > > Baseline v4.10.0 : 60316 Mbit/s > > Current 4.11.0-rc6: 47491 Mbit/s > > This patch : 60662 Mbit/s > (should instead state "Jesper's patch" or "His patch") > Yes, you are correct of course. > Ran same test (8 parallel netperf TCP_STREAMs) with this patch applied: > > This patch 60106 Mbit/s (average of 7 iteration 60 sec runs) > > With these speeds I'm starting to hit the memory bandwidth of my machines. > Thus, the 60 GBit/s measurement cannot be used to validate the > performance impact of reverting this compared to my softirq patch, it > only shows we fixed the regression. (I'm suspicious as I see a higher > contention on the page allocator lock (4% vs 1.3%) with this patch and > still same performance... but lets worry about that outside the rc-series). > Well, in itself that limitation highlights that evaluating this is challenging and needs careful treatment. Otherwise two different approaches can seem equivalent only because a hardware-related bottleneck was at play. -- Mel Gorman SUSE Labs
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH] Revert "mm, page_alloc: only use per-cpu allocator for irq-safe requests" Mel Gorman <mgorman@techsingularity.net> - 2017-04-15 17:00 +0200
Re: [PATCH] Revert "mm, page_alloc: only use per-cpu allocator for irq-safe requests" Jesper Dangaard Brouer <brouer@redhat.com> - 2017-04-15 21:30 +0200
Re: [PATCH] Revert "mm, page_alloc: only use per-cpu allocator for irq-safe requests" Mel Gorman <mgorman@techsingularity.net> - 2017-04-15 22:00 +0200
csiph-web