So the process is in D state ever since I wrote the first mail, just for
100MB writes. Even if it still would do something, it would be extremely
slow. Sysrq-w then shows:
So it's normal to catch such trace for 99% times. But do you mean the
writeout bandwidth is lower than expected?
If it really is still doing something, it is *ways* slower. Once I added
bdi support, it finishes to write the 100MB file in my kvm test instance
within a few seconds. Right now it is running for hours already... As I
added a dump_stack() to our writepages() method, I also see that this
function is never called.
In your case it should be the default/forker thread that's doing the
(suboptimal) writeout:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 17 0.0 0.0 0 0 ? S 21:12 0:00 [bdi-default]
Ah thanks. Good to know, I will starting why this isn't doing anything.
In normal cases there are the flush-* threads doing the writeout:
root 1146 0.0 0.0 0 0 ? S 21:12 0:00 [flush-8:0]
[...]
It's long time ago when the per-bdi writeback is introduced, I suspect.
Ok, I can start to test if 2.6.32 also already deadlocks.
I found the commit, it's introduced right in .32, hehe.
commit 03ba3782e8dcc5b0e1efe440d33084f066e38cae
Author: Jens Axboe<jens.axboe@xxxxxxxxxx>
Date: Wed Sep 9 09:08:54 2009 +0200
writeback: switch to per-bdi threads for flushing data
This gets rid of pdflush for bdi writeout and kupdated style cleaning.
Yeah, that is why I wrote 2.6.32. But I just tested it - with 2.6.32 it
also works without additional bdi code. Sometime later this week I will
try to figure out the exact kernel and then commit causing the issue
(2.6.35 had several bdi additions I think).
Cheers,
Bernd
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
