-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
I took Mindaugas idea of not converting kmem to use the kmem_map, but to take the opportunity to figure out which allocations are actually made from interrupt context during the malloc kmem transition and to convert those allocation to either move allocation out of interrupt context of make dedicated pools form them. The patch provided includes the changed extent as well as a changed implementation of kmem, which provides page aligned memory for allocation >= PAGE_SIZE. The interface between the pool-subsystem and uvm_km is changed by passing the pool_allocators page_size to the uvm_km functions, the idea behind this is to have multiply default pool_allocators with different pool-page-sizes to lower inner fragmentation within the pools. In order to support those different-pool-page-sizes the kernel_map and kmem_map gained caches for virtual addresses not only for PAGE_SIZE but low integer multiplies of PAGE_SIZE. These large then PAGE_SIZE caches are used by the the larger the PAGE_SIZE allocations in kmem. Initialization of the kmem_map is moved to the uvm_km inialization. The next steps I'd like to tackle are to remove the "lazy" initialization from the pool-subsystem, but to have it initialized during the uvm_km phase, this will allow for some cleanup in the pool code as well as bringing different pool-page-sizes for the default allocator to life. This requires to move some pool_init in certain pmaps from pmap_bootstrap to pmap_init this should have no ill effects as all those pools require either the kernel_map or kmem_map to be installed which isn't the case until uvm_km_init has run therefor no allocations could have taken place before this point uvm_init anyway. http://ftp.netbsd.org/pub/NetBSD/misc/para/kmem-pool-uvm-extent.patch <http://ftp.netbsd.org/pub/NetBSD/misc/para/kmem-pool-uvm-extent.patch> Lars -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2fTtsACgkQcxuYqjT7GRY6LgCfYcw6US1/XW6v402I7kh05NLW GFQAnRgU2xFkgwPTx1YD3vsLx8UfuHOS =xalA -----END PGP SIGNATURE-----
