On 04/12/13 01:07, Lars Heidieker wrote:
On 12/03/2013 12:03 PM, David Sainty wrote:On 03/12/13 23:30, Lars Heidieker wrote:On 12/03/2013 11:09 AM, David Sainty wrote:I believe I'm seeing pretty much the same problem, on a stock NetBSD 6.1 amd64 Xen DOMU. Usually happens during /etc/daily for some reason, but sadly not reliably, nor when I run /etc/daily in a tight loop. But it does seem to happen every few days, and I can't drop to ddb when it does. pool_cache_put_slow() has to allocate some administrative storage, via vmem_alloc(), then uvm_km_kmem_alloc(). In uvm_km_kmem_alloc() it calls first vmem_alloc() and then uvm_pagealloc(). If uvm_pagealloc() fails, it calls vmem_free() on the allocation from vmem_alloc() and returns ENOMEM. The problem is that vmem_free() attempts to re-pool the allocation (if QCACHE is defined), which starts the whole process again.The patch is not right, it leads to inconsistencies. It's fixed on the netbsd-6 branch already. vmem_free(kmem_va_arena, va, size); should be vmem_free(vm, va, size);Hmmm, yes, true. But do you think that alone will solve the low memory triggered problem?Yes.At a glance they seem like independent problems to me...The recursion happened due to freeing to the wrong arena. Take a look at the pool_allocator_meta and how vmem recurses. It's one vmem arena (kmem_va_arena) using quantum caches and one (actually two kmem_meta_arena(s) stacked on top of kmem_meta_arena) for meta allocations eg pool_allocator_meta those arenas are stacked up on one arena without quatum caching (kmem_arena). So "normal" allocations utilized this cache, but no pool_caches are involved for "meta" allocations. So it might recurse once while switching to allocate via the kmem_meta_arena and from there on no pool_caches are involved.
I see, yes, because qcache_max is zero for those arenas, so vmem_free() is safe. Excellent! Thanks for the explanation.
http://releng.netbsd.org/cgi-bin/req-6.cgi?show=989