linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Bob Peterson <rpeterso@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Steven Whitehouse <swhiteho@redhat.com>,
	Andrew Lutomirski <luto@kernel.org>,
	Andreas Gruenbacher <agruenba@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	linux-mm <linux-mm@kvack.org>
Subject: Re: [RFC][PATCH] make global bitlock waitqueues per-node
Date: Tue, 20 Dec 2016 09:31:18 -0800	[thread overview]
Message-ID: <CA+55aFxVzes5Jt-hC9BLVSb99x6K-_WkLO-_JTvCjhf5wuK_4w@mail.gmail.com> (raw)
In-Reply-To: <156a5b34-ad3b-d0aa-83c9-109b366c1bdf@linux.intel.com>

On Mon, Dec 19, 2016 at 4:20 PM, Dave Hansen
<dave.hansen@linux.intel.com> wrote:
> On 12/19/2016 03:07 PM, Linus Torvalds wrote:
>>     +wait_queue_head_t *bit_waitqueue(void *word, int bit)
>>     +{
>>     +       const int __maybe_unused nid = page_to_nid(virt_to_page(word));
>>     +
>>     +       return __bit_waitqueue(word, bit, nid);
>>
>> No can do. Part of the problem with the old coffee was that it did that
>> virt_to_page() crud. That doesn't work with the virtually mapped stack.
>
> Ahhh, got it.
>
> So, what did you have in mind?  Just redirect bit_waitqueue() to the
> "first_online_node" waitqueues?

That was my initial thought, but now that I'm back home and look at
the code, I realize:

 - we never merged the PageWaiters patch. I thought we already did,
because I didn't think there was any confusion left, but that was
clearly just in my dreams.

   I was surprised that you'd see the cache ping-pong with per-page
contention bit, but thought that maybe your benchmark was some kind of
broken "fault in the same page over and over again on multiple nodes"
thing. But it was simpler than that - you simply don't have the
per-page contention bit at all.

   And quite frankly, I still suspect that just doing the per-page
contention bit will solve everything, and we don't want to do the
numa-spreading bit_waitqueue() at all.

 - but if I'm wrong, and you can still see numa issues even with the
per-page contention bit in place, we should just treat
"bit_waitqueue()" separately from the page waitqueue, and just have a
separate (non-node) array for the bit-waitqueue.

I'll go back and try to see why the page flag contention patch didn't
get applied.

           Linus

  parent reply	other threads:[~2016-12-20 17:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-19 22:58 [RFC][PATCH] make global bitlock waitqueues per-node 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 [this message]
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
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=CA+55aFxVzes5Jt-hC9BLVSb99x6K-_WkLO-_JTvCjhf5wuK_4w@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --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 \
    /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;
as well as URLs for NNTP newsgroup(s).