> I think I know what is doing this, but I would like to be certain. The
> max-writes-per-cycle choke didn't used to apply to the five-second
> writebacks, now it does. I didn't think that would cause trouble, but
> I appear to have been wrong. Can you please rerun your test after
> doing
>
> # echo "40 5000 64 256 5 3000 500 1884 2" >/proc/sys/vm/bdflush
I've tried it, and it appears to be better. I spent a lot of time playing
around with these settings (before I got your email), trying to get
once-per-second writes cheaply, before I realized bdflush was a thread and
therefore interruptable.
The 5000 blocks makes it behave better. It seems to keep up with my
particular I/O test. However, that just means it scales up as far as this
particular test system. With all the talk about 'enterprise' systems,
perhaps the algorithm should be made more self-aware, and also more safe.
The safety issue comes from the fact that without a periodic sync, there
appears to be no limit to how old a buffer can get. The nfract limit means
there is a *block* limit, but I'm referring to directly configurable
limits of dirty buffer ages. Recoverability is a big issue with databases,
and currently all block I/O goes through the buffer cache. Block-based age
limits tend to mean that the more RAM a system has, the less data it will
to recover from a crash in these situations.
It would also be nice if bdflush took advantage of idle time to step up
the write limit, and perhaps to eventually auto-detect what kind of limits
there are to the writing speed available to it, so it can get the data out
as quickly as possible without affecting response time.
Here's a sample of 'vmstat 2' with the same data thrown at it. The very
fast writes are, I think, a result of the fact that the SCSI controller
has a 64MB cache (some 40% of which buffers writes).
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
2 0 0 7772 8312 187616 10232 0 0 0 2500 1536 338 88 8 3
1 1 0 7772 8212 187640 10232 0 0 1 0 1360 78 88 7 5
2 0 1 7772 8188 187668 10232 0 0 1 913 847 33 94 5 1
2 0 0 7772 8216 187648 10232 0 0 1 1588 1311 229 84 8 8
2 0 0 7772 8252 187576 10232 0 0 0 0 1169 10 86 14 0
2 0 1 7772 8228 187600 10232 0 0 0 1738 1135 147 90 10 0
2 0 0 7772 8276 187624 10232 0 0 0 763 1593 115 89 11 0
2 0 0 7772 8304 187596 10232 0 0 0 0 1982 74 83 10 6
2 0 0 7772 8300 187600 10232 0 0 0 2500 1718 328 85 8 7
2 0 0 7772 8240 187660 10232 0 0 1 0 1637 60 88 8 4
2 0 0 7772 8196 187716 10232 0 0 1 0 1283 18 90 9 1
2 0 0 7772 8236 187680 10232 0 0 0 2500 1244 262 92 7 1
2 0 0 7772 8268 187648 10232 0 0 1 0 1691 36 86 10 4
2 0 0 7772 8268 187648 10232 0 0 0 0 1383 105 87 6 7
2 0 0 7772 8268 187648 10232 0 0 0 2500 1610 347 87 8 5
2 0 0 7772 8268 187648 10232 0 0 0 0 1483 88 88 6 6
2 0 1 7772 8268 187772 10232 0 0 10 1243 1122 144 79 13 8
2 0 1 7772 8252 187772 10232 0 0 0 2346 1488 258 91 6 3
2 0 0 7772 8252 187772 10232 0 0 0 1412 1961 1488 87 9 4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/