From: Nicholas Piggin <npiggin@gmail.com> To: Mel Gorman <mgorman@techsingularity.net> Cc: Linus Torvalds <torvalds@linux-foundation.org>, Dave Hansen <dave.hansen@linux.intel.com>, 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>, linux-mm <linux-mm@kvack.org> Subject: Re: [PATCH 2/2] mm: add PageWaiters indicating tasks are waiting for a page bit Date: Tue, 3 Jan 2017 22:29:58 +1000 [thread overview] Message-ID: <20170103222958.4a2ce0e6@roar.ozlabs.ibm.com> (raw) In-Reply-To: <20170103102439.4fienez2fkgqwbrd@techsingularity.net> On Tue, 3 Jan 2017 10:24:39 +0000 Mel Gorman <mgorman@techsingularity.net> wrote: > On Thu, Dec 29, 2016 at 03:26:15PM +1000, Nicholas Piggin wrote: > > > And I fixed that too. > > > > > > Of course, I didn't test the changes (apart from building it). But > > > I've been running the previous version since yesterday, so far no > > > issues. > > > > It looks good to me. > > > > FWIW, I blindly queued a test of Nick's patch, Linus' patch on top and > PeterZ's patch using 4.9 as a baseline so all could be applied cleanly. > 3 machines were used, one one of them NUMA with 2 sockets. The UMA > machines showed nothing unusual. Hey thanks Mel. > > kernel building showed nothing unusual on any machine > > git checkout in a loop showed; > o minor gains with Nick's patch > o no impact from Linus's patch > o flat performance from PeterZ's > > git test suite showed > o close to flat performance on all patches > o Linus' patch on top showed increased variability but not serious I'd be really surprised if Linus's patch is actually adding variability unless it is just some random cache or branch predictor or similar change due to changed code sizes. Testing on skylake CPU showed the old sequence takes a big stall with the load-after-lock;op hazard. So I wouldn't worry about it too much, but maybe something interesting to look at for someone who knows x86 microarchitectures well. > > will-it-scale pagefault tests > o page_fault1 and page_fault2 showed no differences in processes > > o page_fault3 using processes did show some large losses at some > process counts on all patches. The losses were not consistent on > each run. There also was no consistently at loss with increasing > process counts. It did appear that Peter's patch had fewer > problems with only one thread count showing problems so it > *may* be more resistent to the problem but not completely and > it's not obvious why it might be so it could be a testing > anomaly Okay. page_fault3 has each process doing repeated page faults on their own 128MB file in /tmp. Unless they fill memory and start to reclaim, (which I believe must be happening in Dave's case) there should be no contention on page lock. After the patch, the uncontended case should be strictly faster when there is no contention. When there is contention, there is an added cost of setting and clearing page waiters bit. Maybe there is some other issue there... are you seeing the losses in uncontended case, contended, or both? Thanks, Nick
WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Piggin <npiggin@gmail.com> To: Mel Gorman <mgorman@techsingularity.net> Cc: Linus Torvalds <torvalds@linux-foundation.org>, Dave Hansen <dave.hansen@linux.intel.com>, 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>, linux-mm <linux-mm@kvack.org> Subject: Re: [PATCH 2/2] mm: add PageWaiters indicating tasks are waiting for a page bit Date: Tue, 3 Jan 2017 22:29:58 +1000 [thread overview] Message-ID: <20170103222958.4a2ce0e6@roar.ozlabs.ibm.com> (raw) In-Reply-To: <20170103102439.4fienez2fkgqwbrd@techsingularity.net> On Tue, 3 Jan 2017 10:24:39 +0000 Mel Gorman <mgorman@techsingularity.net> wrote: > On Thu, Dec 29, 2016 at 03:26:15PM +1000, Nicholas Piggin wrote: > > > And I fixed that too. > > > > > > Of course, I didn't test the changes (apart from building it). But > > > I've been running the previous version since yesterday, so far no > > > issues. > > > > It looks good to me. > > > > FWIW, I blindly queued a test of Nick's patch, Linus' patch on top and > PeterZ's patch using 4.9 as a baseline so all could be applied cleanly. > 3 machines were used, one one of them NUMA with 2 sockets. The UMA > machines showed nothing unusual. Hey thanks Mel. > > kernel building showed nothing unusual on any machine > > git checkout in a loop showed; > o minor gains with Nick's patch > o no impact from Linus's patch > o flat performance from PeterZ's > > git test suite showed > o close to flat performance on all patches > o Linus' patch on top showed increased variability but not serious I'd be really surprised if Linus's patch is actually adding variability unless it is just some random cache or branch predictor or similar change due to changed code sizes. Testing on skylake CPU showed the old sequence takes a big stall with the load-after-lock;op hazard. So I wouldn't worry about it too much, but maybe something interesting to look at for someone who knows x86 microarchitectures well. > > will-it-scale pagefault tests > o page_fault1 and page_fault2 showed no differences in processes > > o page_fault3 using processes did show some large losses at some > process counts on all patches. The losses were not consistent on > each run. There also was no consistently at loss with increasing > process counts. It did appear that Peter's patch had fewer > problems with only one thread count showing problems so it > *may* be more resistent to the problem but not completely and > it's not obvious why it might be so it could be a testing > anomaly Okay. page_fault3 has each process doing repeated page faults on their own 128MB file in /tmp. Unless they fill memory and start to reclaim, (which I believe must be happening in Dave's case) there should be no contention on page lock. After the patch, the uncontended case should be strictly faster when there is no contention. When there is contention, there is an added cost of setting and clearing page waiters bit. Maybe there is some other issue there... are you seeing the losses in uncontended case, contended, or both? Thanks, Nick -- 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:[~2017-01-03 12:30 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-12-25 3:00 [PATCH 0/2] PageWaiters again Nicholas Piggin 2016-12-25 3:00 ` Nicholas Piggin 2016-12-25 3:00 ` [PATCH 1/2] mm: Use owner_priv bit for PageSwapCache, valid when PageSwapBacked Nicholas Piggin 2016-12-25 3:00 ` Nicholas Piggin 2016-12-25 5:13 ` Hugh Dickins 2016-12-25 5:13 ` Hugh Dickins 2016-12-25 3:00 ` [PATCH 2/2] mm: add PageWaiters indicating tasks are waiting for a page bit Nicholas Piggin 2016-12-25 3:00 ` Nicholas Piggin 2016-12-25 21:51 ` Linus Torvalds 2016-12-25 21:51 ` Linus Torvalds 2016-12-26 1:16 ` Nicholas Piggin 2016-12-26 1:16 ` Nicholas Piggin 2016-12-26 19:07 ` Linus Torvalds 2016-12-26 19:07 ` Linus Torvalds 2016-12-27 11:19 ` Nicholas Piggin 2016-12-27 11:19 ` Nicholas Piggin 2016-12-27 18:58 ` Linus Torvalds 2016-12-27 18:58 ` Linus Torvalds 2016-12-27 19:23 ` Linus Torvalds 2016-12-27 19:23 ` Linus Torvalds 2016-12-27 19:24 ` Linus Torvalds 2016-12-27 19:40 ` Linus Torvalds 2016-12-27 20:17 ` Linus Torvalds 2016-12-27 20:17 ` Linus Torvalds 2016-12-28 3:53 ` Nicholas Piggin 2016-12-28 3:53 ` Nicholas Piggin 2016-12-28 19:17 ` Linus Torvalds 2016-12-28 19:17 ` Linus Torvalds 2016-12-29 4:08 ` Nicholas Piggin 2016-12-29 4:08 ` Nicholas Piggin 2016-12-29 4:16 ` Linus Torvalds 2016-12-29 5:26 ` Nicholas Piggin 2016-12-29 5:26 ` Nicholas Piggin 2017-01-03 10:24 ` Mel Gorman 2017-01-03 10:24 ` Mel Gorman 2017-01-03 12:29 ` Nicholas Piggin [this message] 2017-01-03 12:29 ` Nicholas Piggin 2017-01-03 17:18 ` Mel Gorman 2017-01-03 17:18 ` Mel Gorman 2016-12-29 22:16 ` [PATCH] mm/filemap: fix parameters to test_bit() Olof Johansson
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=20170103222958.4a2ce0e6@roar.ozlabs.ibm.com \ --to=npiggin@gmail.com \ --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 \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.