On Wed, 2 Nov 2016 09:18:37 -0600
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Nov 2, 2016 at 1:03 AM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote:
> > + __wake_up_locked_key(q, TASK_NORMAL, &key);
> > + if (!waitqueue_active(q) || !key.page_match) {
> > + ClearPageWaiters(page);
>
> Is that "page_match" optimization really worth it? I'd rather see
> numbers for that particular optimization. I'd rather see the
> contention bit being explicitly not precise.
If you don't have that, then a long-waiting waiter for some
unrelated page can prevent other pages from getting back to
the fastpath.
Contention bit is already explicitly not precise with this patch
(false positive possible), but in general the next wakeup will
clean it up. Without page_match, that's not always possible.
It would be difficult to get numbers that aren't contrived --
blatting a lot of slow IO and waiters in there to cause collisions.
And averages probably won't show it up. But the idea is we don't
want the workload to randomly slow down.
> Also, it would be lovely to get numbers against the plain 4.8
> situation with the per-zone waitqueues. Maybe that used to help your
> workload, so the 2.2% improvement might be partly due to me breaking
> performance on your machine.
Oh yeah that'll hurt a bit. The hash will get spread over non-local
nodes now. I think it was only a 2 socket system, but remote memory
still takes a latency hit. Hmm, I think keeping the zone waitqueue
just for pages would be reasonable, because they're a special case?
Thanks,
Nick
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>