Hi! On Thu, 25 Sep 2014 09:51:25 +0200, Richard Braun <rbr...@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
pgplr4TJMLORF.pgp
Description: PGP signature