RFC: using worker threadpool to speed up clear_huge_page() by up to 5x

From: kpusukur
Date: Sun Jul 17 2016 - 15:35:42 EST


This is a multi-part message in MIME format.A prototype implementation of multi-threaded clear_huge_page() function based on the kernel work queue mechansim speeds up the function by up to 5x. The existing code requires 320ms to clear a 2Gb huge page on a Sparc M7 processor, while the multi-threaded version achieves this in 65ms using 16 threads. 8Mb huge pages see a 3.7x improvement, from 1400us to 380us. Even though the M7 has a vast number of CPUs at its disposal, this idea could be utilized even on small multicore systems with just a few CPUs to achieve a significant performance gain. For instance, on a x86_64 system (ie, with an Intel E5-2630 v2), while it speeds up the function by 3.8x using 4 threads in clearing 1GB page, 3.7x using 4 threads in clearing 2MB page. The principal application we have in mind that would benefit from this is an in-memory database which uses hundreds of huge pages, and starts up 2.5x faster using this implementation. In other words, it improves database down-times by 2.5x.

Here is a table which shows speedups in clearing 2GB huge pages on Sparc M7 (by default it takes 320 milliseconds). Time is in milliseconds.
#workers Time
2 166
4 87
8 70
16 65
32 66
64 66

Please see attached patch for an implementation, which serves to illustrate the idea. There are many ways to improve it and tune it for different sized systems, and some of the issues we are thinking about are:
1) How many tasks (workers) to use? There is just so much memory bandwidth, so scaling is not stellar, so it might be satisfactory to shoot for modest performance without tying up too many processors.
2) The system load needs to be taken into account somehow..
3) Numa issues might/should influence which cpus are chosen for the work.

We would welcome feedback and discussion of potential problems.

We would also like to hear ideas for other areas in the kernel where a similar technique could be employed. For example, we've also applied this idea to copy on write operations for huge pages and it achieves around 20x speedup.

Thank you.

Best
Kishore Pusukuri