[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Main Index |
Thread Index |