[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: System getting stuck by GCC invocation
From: |
Richard Braun |
Subject: |
Re: System getting stuck by GCC invocation |
Date: |
Thu, 25 Sep 2014 14:08:16 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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