linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

  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).