Re: pool_cache_get behavior

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

> > 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?

What I don't understand around here is, do we really want to keep a map locked
while paging its pages?  My understanding is paging never changes (adds /
deletes) any map entries in the map.

I guess we can release the map's lock by marking pages as busy ("this page is
being paged").  Then we can make map locks spin locks, because we don't do
any slow task with it...

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635