Re: System getting stuck by GCC invocation

[Richard Braun]

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