From: Mel Gorman <mgorman@techsingularity.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andy Lutomirski <luto@amacapital.net>,
Andreas Gruenbacher <agruenba@redhat.com>,
Andy Lutomirski <luto@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Bob Peterson <rpeterso@redhat.com>,
Steven Whitehouse <swhiteho@redhat.com>,
linux-mm <linux-mm@kvack.org>
Subject: Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit
Date: Thu, 27 Oct 2016 10:07:42 +0100 [thread overview]
Message-ID: <20161027090742.GG2699@techsingularity.net> (raw)
In-Reply-To: <20161027080852.GC3568@worktop.programming.kicks-ass.net>
On Thu, Oct 27, 2016 at 10:08:52AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 27, 2016 at 12:07:26AM +0100, Mel Gorman wrote:
> > > but I consider PeterZ's
> > > patch the fix to that, so I wouldn't worry about it.
> > >
> >
> > Agreed. Peter, do you plan to finish that patch?
>
> I was waiting for you guys to hash out the 32bit issue. But if we're now
> OK with having this for 64bit only, I can certainly look at doing a new
> version.
>
I've no problem with it being 64-bit only.
> I'll have to look at fixing Alpha's bitops for that first though,
> because as is that patch relies on atomics to the same word not needing
> ordering, but placing the contended/waiters bit in the high word for
> 64bit only sorta breaks that.
>
I see the problem assuming you're referring to the requirement that locked
and waiter bits are on the same word. Without it, you need a per-arch helper
that forces ordering or takes a spinlock. I doubt it's worth the trouble.
> Hurm, we could of course play games with the layout, the 64bit only
> flags don't _have_ to be at the end.
>
> Something like so could work I suppose, but then there's a slight
> regression in the page_unlock() path, where we now do an unconditional
> spinlock; iow. we loose the unlocked waitqueue_active() test.
>
I can't convince myself it's worthwhile. At least, I can't see a penalty
of potentially moving one of the two bits to the high word. It's the
same cache line and the same op when it matters.
> We could re-instate this with an #ifndef CONFIG_NUMA I suppose.. not
> pretty though.
>
> Also did the s/contended/waiters/ rename per popular request.
>
> ---
> include/linux/page-flags.h | 19 ++++++++
> include/linux/pagemap.h | 25 ++++++++--
> include/trace/events/mmflags.h | 7 +++
> mm/filemap.c | 94 +++++++++++++++++++++++++++++++++++++----
> 4 files changed, 130 insertions(+), 15 deletions(-)
>
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -73,6 +73,14 @@
> */
> enum pageflags {
> PG_locked, /* Page is locked. Don't touch. */
> +#ifdef CONFIG_NUMA
> + /*
> + * This bit must end up in the same word as PG_locked (or any other bit
> + * we're waiting on), as per all architectures their bitop
> + * implementations.
> + */
> + PG_waiters, /* The hashed waitqueue has waiters */
> +#endif
> PG_error,
> PG_referenced,
> PG_uptodate,
I don't see why it should be NUMA-specific even though with Linus'
patch, NUMA is a concern. Even then, you still need a 64BIT check
because 32BIT && NUMA is allowed on a number of architectures.
Otherwise, nothing jumped out at me but glancing through it looked very
similar to the previous patch.
--
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>
next prev parent reply other threads:[~2016-10-27 9:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAHc6FU4e5sueLi7pfeXnSbuuvnc5PaU3xo5Hnn=SvzmQ+ZOEeg@mail.gmail.com>
[not found] ` <CALCETrUt+4ojyscJT1AFN5Zt3mKY0rrxcXMBOUUJzzLMWXFXHg@mail.gmail.com>
2016-10-26 16:32 ` CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Linus Torvalds
2016-10-26 17:15 ` Linus Torvalds
2016-10-26 17:58 ` Linus Torvalds
2016-10-26 18:04 ` Bob Peterson
2016-10-26 18:10 ` Linus Torvalds
2016-10-26 19:11 ` Bob Peterson
2016-10-26 21:01 ` Bob Peterson
2016-10-26 21:30 ` Linus Torvalds
2016-10-26 22:45 ` Borislav Petkov
2016-10-26 23:13 ` Borislav Petkov
2016-10-27 0:37 ` Bob Peterson
2016-10-27 12:36 ` Borislav Petkov
2016-10-27 18:51 ` Bob Peterson
2016-10-27 19:19 ` Borislav Petkov
2016-10-27 21:03 ` Bob Peterson
2016-10-27 21:19 ` Borislav Petkov
2016-10-28 8:37 ` [tip:x86/urgent] x86/microcode/AMD: Fix more fallout from CONFIG_RANDOMIZE_MEMORY=y tip-bot for Borislav Petkov
2016-10-26 20:31 ` CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Mel Gorman
2016-10-26 21:26 ` Linus Torvalds
2016-10-26 22:03 ` Mel Gorman
2016-10-26 22:09 ` Linus Torvalds
2016-10-26 23:07 ` Mel Gorman
2016-10-27 8:08 ` Peter Zijlstra
2016-10-27 9:07 ` Mel Gorman [this message]
2016-10-27 9:44 ` Peter Zijlstra
2016-10-27 9:59 ` Mel Gorman
2016-10-27 11:56 ` 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=20161027090742.GG2699@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=agruenba@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).