Re: A new page allocator for UVM

[lars Reichardt <lars%paradoxon.info@localhost>]

On Sun, 22 Dec 2019 21:14:44 +0000
Andrew Doran <ad%netbsd.org@localhost> wrote:

> Hi,
> 
> Anyone interested in taking a look?  This solves the problem we have
> with uvm_fpageqlock.  Here's the code, and the blurb is below:
> 
> 	http://www.netbsd.org/~ad/2019/allocator.diff
> 
...
> 
> Results:
> 
> 	This from a "make -j96" kernel build, with a !DIAGNOSTIC,
> GENERIC kernel on the system mentioned above.  System time is the most
> 	interesting here.  With NUMA disabled in the BIOS:
> 
> 	       74.55 real      1635.13 user       725.04 sys
> before 72.66 real      1653.86 user       593.19 sys	after
> 
> 	With NUMA enabled in the BIOS & the allocator:
> 
> 	       76.81 real      1690.27 user       797.56 sys
> before 71.10 real      1632.42 user       603.41 sys	after
> 
> 	Lock contention before (no NUMA):
> 
> 	Total%  Count   Time/ms          Lock          
> 	------ ------- --------- ----------------------
> 	 99.80 36756212 182656.88 uvm_fpageqlock       
> 
> 	Lock contention after (no NUMA):
> 
> 	Total%  Count   Time/ms          Lock
> 	------ ------- --------- ----------------------
> 	 20.21  196928    132.50 uvm_freelist_locks+40  <all>
> 	 18.72  180522    122.74 uvm_freelist_locks     <all>

Hi Andrew,

I read my way through the patch... very impressive.
Currently I have a patched kernel running and see almost no lock
contention with uvm_freelist_locks, the system is a ryzen 2700.
It seems to have enough cores to make the problem with the old allocator
to appear (no as prominent as with larger machines especially as with
NUMA machines I guess).
The new allocator gets configured with one bucket and 16 colors.
Looks very good to me.

Thanks,
Lars