On Thu, Jan 28, 2010 at 06:55:55PM +0300, Mike Belopuhov wrote:
> could someone please enlighten me how this uvm_pseg_get is supposed
> to work?
>
> uvm_pseg_get
> mtx_enter(&uvm_pseg_lck);
> `-> uvm_pseg_init
> `-> uvm_km_valloc
> `-> uvm_km_valloc_align
> `-> uvm_map
> `-> vm_map_lock <-- sleeping lock
It's supposed to work like that, except for the sleeping on the lock (if
the lock is busy, it should fail instead).
pseg was written to remove a deadlock during (heavy) paging. The system
works by holding on to a number of virtual addresses, each containing an
area of MAXBSIZE size. The first of these areas is always populated, so
that paging never fails (this was an issue when the diff was created).
The next are allocated when needed and freed when no longer needed, so
that the pager can speed up io (by queueing more) without holding on to
that memory when not doing anything.
uvm_km_valloc probably needs to be replaced by uvm_km_kmemalloc using
flags = UVM_KMF_TRYLOCK|UVM_KMF_VALLOC.
It is important that these are only virtual addresses, with no physical
memory backing them, so that pages from userland processes can be mapped
in to perform the IO for paging out.
> Debugger(10,d73eeeac,d03e0ee2,d06ab9a0,0) at Debugger+0x4
> panic(d020319c,d73eeecc,d03ad948,d06ab980,d51c8000) at panic+0x61
> mtx_enter(d06ab980,d51c8000,d51d8000,d02f70c5,10000) at mtx_enter+0x5c
> uvm_pseg_release(d51c8000,10,d73eeefc,d02f41d4,50) at uvm_pseg_release+0x64
> uvm_aio_aiodone(d0f422e4,0,d11c1c3c,d73eef90,d02e763d) at uvm_aio_aiodone+0xba
> uvm_aiodone_daemon(d11c1c3c) at uvm_aiodone_daemon+0x97
> Bad frame pointer: 0xd079ceb8
>
> OpenBSD 4.6.
>
> Or am I missing something?
You're not missing anything. My fault for misinterpreting the
distinction between uvm_km_valloc{,_wait}.
I don't have a reproducable case. How did you hit the panic?
Ciao,
--
Ariane
