Re: Mirage/kFreeBSD on GitHub

["Robert N. M. Watson" <robert.watson@xxxxxxxxxxxx>]

On 4 Aug 2012, at 18:47, PALI Gabor Janos wrote:

> This helped me to find the thread with this address in the output of the
> "show threads" command (which has become 100096 in my case).  Here is the
> corresponding backtrace for that thread:
> 
> db> bt 100096
> Tracing pid 0 tid 100096 td 0xfffffe0005273000
> sched_switch() at sched_switch+0x19f
> mi_switch() at mi_switch+0x208
> sleepq_switch() at sleepq_switch+0xfc
> sleepq_wait() at sleepq_wait+0x4d
> _sleep() at _sleep+0x3fc
> kmem_back() at kmem_back+0x1a3
> kmem_malloc() at kmem_malloc+0x1f8
> uma_large_malloc() at uma_large_malloc+0x4a
> malloc() at malloc+0x15d
> caml_aligned_malloc_for_major() at caml_aligned_malloc_for_major+0x2f
> caml_alloc_for_heap() at caml_alloc_for_heap+0x1e
> caml_alloc_shr() at caml_alloc_shr+0x10e
> caml_alloc_string() at caml_alloc_string+0xbd
> caml_c_call() at caml_c_call+0x20
> 
> 
> Perhaps the rest of the kernel is just simply too busy with allocating the
> requested memory?
> 
> Note that this test tries to allocate a lot of memory: 1 million instances
> of strings with the given sizes: first 1, then 500, and 2500 -- that is
> where the test hangs after around 372,000 allocations.  But I suppose the
> garbage collector should be dropping the unused instances (since they are just
> allocted, not even used) continuously, freeing up the memory on the other
> side.


You can use "show uma" and "show malloc" to show kernel UMA and malloc 
statistics, which include both allocation counts and net outstanding 
allocations.

Robert