Re: System getting stuck by GCC invocation

[Thomas Schwinge]

Hi!

On Thu, 25 Sep 2014 09:51:25 +0200, Richard Braun <rbraun@sceen.net> wrote:
> On Thu, Sep 25, 2014 at 08:13:57AM +0200, Thomas Schwinge wrote:
> > This testing was done in a QEMU/KVM Hurd system, configured with 1536 GiB
> > of RAM.  Some time after beginning to execute the jc1 command, the system
> > stops responding, but still consumes 100 % host CPU time.  And, if QEMU's
> > built-in gdbserver is to be believed, it is still doing "something":
> 
> You can also use the in-kernel debugger for more information, in
> particular show all threads, to see if it's a thread storm caused by
> too many concurrent page cache writebacks. This is the main issue I
> have when building "large" files (see [1]).

> [1] https://www.sceen.net/iceweasel-31-on-debian-gnuhurd/

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.


As an experiment, (on top of the current Debian GNU Mach sources) I
reverted GNU Mach commits c7cdf5ff96e7c3bb008877893aa194908dca2185
»Increate the pageout thread priority«. and
91f0887ca2345c2bd02747e4b437076641d77cd9 »Tune pageout parameters«.  Then
"the issue" happens later (as to be expected, because pageout starts
later).  Again, no task got more than 17 threads.

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.


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]


Grüße,
 Thomas

pgp_u_nsV79x2.pgp
Description: PGP signature