Re: pool_cache_get behavior

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

haad <haaaad%gmail.com@localhost> wrote:
> ad@
> KM_NOSLEEP... probably due to that implying UVM_MAP_TRYLOCK
> The issue is that parts of kernel_map are pageable. Paging can take a
> long time, and the map can be held locked while paging.
> 
> Therefore when we do a NOSLEEP allocation from kernel_map, it's also
> implicitly a TRYLOCK one because we can't wait to lock the map.

FYI: Related problem is described in PR/38270.  In this case, I guess
kmem_map, which is used by pool(9) and is VM_MAP_INTRSAFE, could avoid
trylock because map is locked by a spin-mutex (at IPL_VM).

It is not the case for kernel_map (at IPL_DEFAULT), used by kmem(9).
There is yamt-kmem branch which has been revamping this.  yamt?

-- 
Mindaugas