Hi,
I would like to talk about the way to remove the mmap_sem contention we
could see on large threaded systems.
I already resurrected the Speculative Page Fault patchset from Peter
Zijlstra [1]. This series allows concurrency between page fault handler and
the other thread's activity. Running a massively threaded benchmark like
ebizzy [2] on top of this kernel shows that there is an opportunity to
scale far better on large systems (x2). But the SPF series is addressing
only one part of the issue, and there is a need to address the other part
of picture.
There have been some discussions last year about the range locking but this
has been put in hold, especially because this implies huge change in the
kernel as the mmap_sem is used to protect so many resources (should we need
to protect the process command line with the mmap_sem ?), and sometimes the
assumption is made that the mmap_sem is protecting code against concurrency
while it is not dealing clearly with the mmap_sem.
This will be a massive change and rebasing such a series will be hard, so
it may be far better to first agreed on best options to improve mmap_sem's
performance and scalability. There are several additional options on the
table, including range locking, multiple fine-grained locks, etc...
In addition, I would like to discuss the options and the best way to make
the move smooth in breaking or replacing the mmap_sem.
Peoples (sorry if I missed someone) :
Andrea Arcangeli
Davidlohr Bueso
Michal Hocko
Anshuman Khandual
Andi Kleen
Andrew Morton
Matthew Wilcox
Peter Zijlstra
Thanks,
Laurent
[1] https://lkml.org/lkml/2018/1/12/515
[2] http://ebizzy.sourceforge.net/
--
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>
