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 kleber.souza at
Wed Jul 1 16:22:25 UTC 2020

On 2020-06-04 11:39, Gavin Guo wrote:
> BugLink:
> [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.


More information about the kernel-team mailing list