For the current development this will be automatically fixed once the
kernel moves to 5.7 (the fix was in 5.5). I leave it to the devel team
whether they want to keep the task open until then.
** Changed in: linux (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Bionic)
Status: New => Triaged
** Changed in: linux (Ubuntu Eoan)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Eoan)
Status: New => Triaged
** Changed in: linux (Ubuntu Focal)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Focal)
Status: New => Triaged
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu)
Status: Incomplete => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1882039
Title:
The thread level parallelism would be a bottleneck when searching for
the shared pmd by using hugetlbfs
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Bionic:
Triaged
Status in linux source package in Eoan:
Triaged
Status in linux source package in Focal:
Triaged
Bug description:
[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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1882039/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
