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]

On 2020-06-04 11:39, Gavin Guo wrote:
> BugLink: https://bugs.launchpad.net/bugs/1882039
> 
> [Impact]
> 
> There is performance overhead observed when many threads
> are using hugetlbfs in the database environment.
> 
> [Fix]
> 
> 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.
> 
> [Test]
> 
> 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
> low.
> 
> 
> 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.

Thanks,
Kleber