APPLIED: [SRU][B/E/F][PATCH 0/1] LP:#1882039 - The thread level parallelism would be a bottleneck when searching for the shared pmd by using hugetlbfs
kleber.souza at canonical.com
Wed Jul 1 16:22:25 UTC 2020
On 2020-06-04 11:39, Gavin Guo wrote:
> BugLink: https://bugs.launchpad.net/bugs/1882039
> There is performance overhead observed when many threads
> are using hugetlbfs in the database environment.
> bdfbd98bc018 hugetlbfs: take read_lock on i_mmap for PMD sharing
> The patch improves the locking by using the read lock instead of the
> write lock. And it allows multiple threads searching the suitable shared
> VMA. As there is no modification inside the searching process. The
> improvement increases the parallelism and decreases the waiting time of
> the other threads.
> The customer stand-up a database with seed data. Then they have a
> loading "driver" which makes a bunch of connections that look like user
> workflows from the database perspective. Finally, the measuring response
> times improvement can be observed for these "users" as well as various
> other metrics at the database level.
> [Regression Potential]
> The modification is only in replacing the write lock to a read one. And
> there is no modification inside the loop. The regression probability is
> Waiman Long (1):
> hugetlbfs: take read_lock on i_mmap for PMD sharing
> mm/hugetlb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied to bionic/linux, eoan/linux and focal/linux.
More information about the kernel-team