From: Mel Gorman <mgorman@techsingularity.net>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
willy@infradead.org, peterz@infradead.org, pagupta@redhat.com,
ttoukan.linux@gmail.com, tariqt@mellanox.com,
netdev@vger.kernel.org, saeedm@mellanox.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] Revert "mm, page_alloc: only use per-cpu allocator for irq-safe requests"
Date: Sat, 15 Apr 2017 20:57:35 +0100 [thread overview]
Message-ID: <20170415195734.avk2zk237a2oe5cd@techsingularity.net> (raw)
In-Reply-To: <20170415212833.30ed3f2b@redhat.com>
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
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@techsingularity.net>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
willy@infradead.org, peterz@infradead.org, pagupta@redhat.com,
ttoukan.linux@gmail.com, tariqt@mellanox.com,
netdev@vger.kernel.org, saeedm@mellanox.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] Revert "mm, page_alloc: only use per-cpu allocator for irq-safe requests"
Date: Sat, 15 Apr 2017 20:57:35 +0100 [thread overview]
Message-ID: <20170415195734.avk2zk237a2oe5cd@techsingularity.net> (raw)
In-Reply-To: <20170415212833.30ed3f2b@redhat.com>
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
next prev parent reply other threads:[~2017-04-15 19:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-15 14:53 [PATCH] Revert "mm, page_alloc: only use per-cpu allocator for irq-safe requests" Mel Gorman
2017-04-15 14:53 ` Mel Gorman
2017-04-15 19:28 ` Jesper Dangaard Brouer
2017-04-15 19:28 ` Jesper Dangaard Brouer
2017-04-15 19:57 ` Mel Gorman [this message]
2017-04-15 19:57 ` Mel Gorman
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=20170415195734.avk2zk237a2oe5cd@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=brouer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=pagupta@redhat.com \
--cc=peterz@infradead.org \
--cc=saeedm@mellanox.com \
--cc=tariqt@mellanox.com \
--cc=ttoukan.linux@gmail.com \
--cc=willy@infradead.org \
/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: link
Be 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.