On Thu, Sep 25, 2014 at 11:55:05AM +0200, Thomas Schwinge wrote: > I reduced the VM's memory configuration to 768 MiB. From »vmstat 1« > running in parallel, I can see that "the issue" appears soon after the > first few MiBs have been written to the default pager (swap). > > KDB's »show all threads« shows a maximum of 20 threads for one task, and > all of the other 62 tasks are below that.
It looks like you've hit the same pageout bug I have. I suggest you disable the VM object cache as I did, by setting vm_object_cached_max to 0 (which could simply be done with gdb if i'm right). > From a total of maybe ten runs, once, I got one task with 66 threads, and > once I got one task (the second in the list, if that has a stable > meaning) with 441 threads -- that, I assume, is a thread storm? In the > latter case, from »vmstat 1« running in parallel, I had observed free > memory as low as 192 KiB (or similar), which the system recovered from, > with free memory jumping to about 30 MiB, and then shortly after "the > issue" happened. 441 looks low, unless they're all runnable. Again, it's more likely a pageout bug. > A few times when I looked with QEMU's gdbserver (for example, in the case > with the 441 threads), when "the issue" happened, it told me the system > is idle: > > (gdb) target remote :1234 > Remote debugging using :1234 > machine_idle (cpu=0) at ../i386/i386at/model_dep.c:207 > 207 } > (gdb) bt > #0 machine_idle (cpu=0) at ../i386/i386at/model_dep.c:207 > #1 0x80126f5a in idle_thread_continue () at ../kern/sched_prim.c:1693 > #2 0x00000000 in ?? () > (gdb) c > Continuing. > ^C > [same] Same here, the pageout daemon does use miliseconds sleeps until its load decreases, which I assume never does in this case. -- Richard Braun
