Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1510385
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit |
| Date | 2016-10-27 17:20 +0200 |
| Message-ID | <swUae-3cE-23@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <swEyt-1qp-21@gated-at.bofh.it> <swEIa-1vJ-31@gated-at.bofh.it> <swFuy-226-17@gated-at.bofh.it> <swP0R-8pq-23@gated-at.bofh.it> <swP0R-8pq-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Oct 27, 2016 at 10:07:42AM +0100, Mel Gorman wrote:
> > 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.
I'm having trouble connecting these here two paragraphs. Or were you
replying to something else?
So the current unlock code does:
wake_up_page()
if (waitqueue_active())
__wake_up() /* takes waitqueue spinlocks here */
While the new one does:
spin_lock(&q->lock);
if (waitqueue_active()) {
__wake_up_common()
}
spin_unlock(&q->lock);
Which is an unconditional atomic op (which go for about ~20 cycles each,
when uncontended).
> > +++ 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.
Oh, I thought we killed 32bit NUMA and didn't check. I can make it
CONFIG_64BIT and be done with it. s/CONFIG_NUMA/CONFIG_64BIT/ on the
patch should do :-)
> Otherwise, nothing jumped out at me but glancing through it looked very
> similar to the previous patch.
Right, all the difference was in the bit being conditional and having a
different name.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Andreas Gruenbacher <agruenba@redhat.com> - 2016-10-26 15:00 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Andy Lutomirski <luto@amacapital.net> - 2016-10-26 18:00 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-26 18:40 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-26 19:20 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-26 20:00 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Bob Peterson <rpeterso@redhat.com> - 2016-10-26 20:10 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-26 20:20 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Bob Peterson <rpeterso@redhat.com> - 2016-10-26 21:20 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Bob Peterson <rpeterso@redhat.com> - 2016-10-26 23:10 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-26 23:40 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Borislav Petkov <bp@suse.de> - 2016-10-27 00:50 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Borislav Petkov <bp@alien8.de> - 2016-10-27 01:20 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Borislav Petkov <bp@alien8.de> - 2016-10-27 16:00 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Bob Peterson <rpeterso@redhat.com> - 2016-10-27 21:00 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Borislav Petkov <bp@alien8.de> - 2016-10-27 21:30 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Bob Peterson <rpeterso@redhat.com> - 2016-10-27 23:10 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Borislav Petkov <bp@alien8.de> - 2016-10-27 23:20 +0200
[tip:x86/urgent] x86/microcode/AMD: Fix more fallout from CONFIG_RANDOMIZE_MEMORY=y tip-bot for Borislav Petkov <tipbot@zytor.com> - 2016-10-28 10:50 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Mel Gorman <mgorman@techsingularity.net> - 2016-10-26 22:40 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-26 23:30 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Mel Gorman <mgorman@techsingularity.net> - 2016-10-27 00:10 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-27 00:20 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Mel Gorman <mgorman@techsingularity.net> - 2016-10-27 01:10 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Mel Gorman <mgorman@techsingularity.net> - 2016-10-27 11:20 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Mel Gorman <mgorman@techsingularity.net> - 2016-10-27 16:50 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Peter Zijlstra <peterz@infradead.org> - 2016-10-27 17:20 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Nicholas Piggin <npiggin@gmail.com> - 2016-10-27 16:10 +0200
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit Peter Zijlstra <peterz@infradead.org> - 2016-10-27 16:50 +0200
csiph-web