From: Nicholas Piggin <npiggin@gmail.com>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
agruenba@redhat.com, rpeterso@redhat.com,
mgorman@techsingularity.net, peterz@infradead.org,
luto@kernel.org, swhiteho@redhat.com,
torvalds@linux-foundation.org
Subject: Re: [RFC][PATCH] make global bitlock waitqueues per-node
Date: Tue, 20 Dec 2016 12:26:15 +1000 [thread overview]
Message-ID: <20161220122615.1f4b494d@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <20161219225826.F8CB356F@viggo.jf.intel.com>
On Mon, 19 Dec 2016 14:58:26 -0800
Dave Hansen <dave.hansen@linux.intel.com> wrote:
> I saw a 4.8->4.9 regression (details below) that I attributed to:
>
> 9dcb8b685f mm: remove per-zone hashtable of bitlock waitqueues
>
> That commit took the bitlock waitqueues from being dynamically-allocated
> per-zone to being statically allocated and global. As suggested by
> Linus, this makes them per-node, but keeps them statically-allocated.
>
> It leaves us with more waitqueues than the global approach, inherently
> scales it up as we gain nodes, and avoids generating code for
> page_zone() which was evidently quite ugly. The patch is pretty darn
> tiny too.
>
> This turns what was a ~40% 4.8->4.9 regression into a 17% gain over
> what on 4.8 did. That gain is a _bit_ surprising, but not entirely
> unexpected since we now get much simpler code from no page_zone() and a
> fixed-size array for which we don't have to follow a pointer (and get to
> do power-of-2 math).
I'll have to respin the PageWaiters patch and resend it. There were
just a couple of small issues picked up in review. I've just got side
tracked with getting a few other things done and haven't had time to
benchmark it properly.
I'd still like to see what per-node waitqueues does on top of that. If
it's significant for realistic workloads then it could be done for the
page waitqueues as Linus said.
Thanks,
Nick
next prev parent reply other threads:[~2016-12-20 2:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-19 22:58 Dave Hansen
[not found] ` <CA+55aFwK6JdSy9v_BkNYWNdfK82sYA1h3qCSAJQ0T45cOxeXmQ@mail.gmail.com>
2016-12-20 0:20 ` Dave Hansen
2016-12-20 2:31 ` Nicholas Piggin
2016-12-20 12:58 ` Mel Gorman
2016-12-20 13:21 ` Nicholas Piggin
2016-12-20 17:31 ` Linus Torvalds
2016-12-20 18:02 ` Linus Torvalds
2016-12-21 8:09 ` Peter Zijlstra
2016-12-21 8:32 ` Peter Zijlstra
2016-12-21 18:02 ` Linus Torvalds
2016-12-21 18:33 ` Nicholas Piggin
2016-12-21 19:01 ` Nicholas Piggin
2016-12-21 19:50 ` Linus Torvalds
2016-12-22 2:07 ` Nicholas Piggin
2016-12-22 19:28 ` Hugh Dickins
2016-12-21 10:26 ` Nicholas Piggin
2016-12-20 2:26 ` Nicholas Piggin [this message]
2016-12-21 12:30 ` Nicholas Piggin
2016-12-21 18:12 ` Linus Torvalds
2016-12-21 18:40 ` Nicholas Piggin
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=20161220122615.1f4b494d@roar.ozlabs.ibm.com \
--to=npiggin@gmail.com \
--cc=agruenba@redhat.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mgorman@techsingularity.net \
--cc=peterz@infradead.org \
--cc=rpeterso@redhat.com \
--cc=swhiteho@redhat.com \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome