> I just reproduced the problem in test10-pre7. Here's the
> output you requested:
>
> vmstat 1
> procs memory swap io system cpu
> r b w swpd free buff cache si so bi bo in cs us sy id
> 0 2 2 0 45764 76000 59520 0 0 0 509 272 508 0 0 100
> 0 2 2 0 45300 76324 59520 0 0 0 636 276 548 1 0 99
> 0 2 2 0 44896 76680 59520 0 0 0 636 273 523 0 0 100
> 0 2 2 0 44088 77392 59520 0 0 0 650 281 1307 0 7 93
> 1 1 2 0 43736 77680 59548 0 0 0 1279 908 2637 1 8 91
> 0 2 3 0 43072 78040 59592 0 0 0 1660 1281 4119 5 6 89
>
> >>> /var/log/kernel output stopped being emitted here <<<
> >>> CRUNCH! <<<
>
> 0 2 3 0 42656 78384 59592 0 0 0 259 271 551 0 0 100
> 0 2 3 0 42656 78384 59592 0 0 0 5 271 499 0 0 100
> 0 2 3 0 42656 78384 59592 0 0 0 5 272 511 0 2 98
> 0 2 3 0 42656 78384 59592 0 0 0 4 268 502 0 0 100
> 0 2 3 0 42656 78384 59592 0 0 0 5 272 508 0 0 100
> 0 2 3 0 42656 78384 59592 0 0 0 5 274 523 0 0 100
test7 had the problem that when the rq queue if full new requests are no
longer
merged together (the disk is slow because it writes a lot of 512 bytes blocks
instead of 128K blocks). There is a patch for this. There still is the
problem that when the rq queue if full other processes can no more access to
*any*
device that uses ll_rw_block() and they remain blocked in D state.
Bye.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Nov 07 2000 - 21:00:23 EST