This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- focal' to 'verification-done-focal'. If the problem still exists, change the tag 'verification-needed-focal' to 'verification-failed-focal'.
If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-focal -- 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: Fix Committed Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Fix Committed 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
