On 09/06/2017 17:01, Michal Hocko wrote: > On Fri 09-06-17 16:20:49, Laurent Dufour wrote: >> This is a port on kernel 4.12 of the work done by Peter Zijlstra to >> handle page fault without holding the mm semaphore. >> >> http://linux-kernel.2935.n7.nabble.com/RFC-PATCH-0-6-Another-go-at-speculative-page-faults-tt965642.html#none >> >> Compared to the Peter initial work, this series introduce a try spin >> lock when dealing with speculative page fault. This is required to >> avoid dead lock when handling a page fault while a TLB invalidate is >> requested by an other CPU holding the PTE. Another change due to a >> lock dependency issue with mapping->i_mmap_rwsem. >> >> This series also protect changes to VMA's data which are read or >> change by the page fault handler. The protections is done through the >> VMA's sequence number. >> >> This series is functional on x86 and PowerPC. >> >> It's building on top of v4.12-rc4 and relies on the change done by >> Paul McKenney to the SRCU code allowing better performance by >> maintaining per-CPU callback lists: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da915ad5cf25b5f5d358dd3670c3378d8ae8c03e >> >> Tests have been made using a large commercial in-memory database on a >> PowerPC system with 752 CPUs. The results are very encouraging since >> the loading of the 2TB database was faster by 20% with the speculative >> page fault. >> >> Since tests are encouraging and running test suite didn't raise any >> issue, I'd like this request for comment series to move to a patch >> series soon. So please feel free to comment. > > What other testing have you done? Other benchmarks (some numbers)? What > about some standard worklaods like kbench? This is a pretty invasive > change so I would expect much more numbers. Thanks Michal for your feedback. I mostly focused on this database workload since this is the one where we hit the mmap_sem bottleneck when running on big node. On my usual victim node, I checked for basic usage like kernel build time, but I agree that's clearly not enough. I try to find details about the 'kbench' you mentioned, but I didn't get any valid entry. Would you please point me on this or any other bench tool you think will be useful here ? > > It would also help to describe the highlevel design of the change here > in the cover letter. This would make the review of specifics much > easier. You're right, I'll try to make a highlevel design. Thanks, Laurent. -- 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>
