> After the initial burst, the system should stabilise,
> starting the writeout of pages before we run low on
> memory. How to handle the initial burst is something
> I haven't figured out yet ... ;)
Well, at least I know that this is expected with the VM, although I do still
think this is bad behavior. If my disk is idle why would I wait until I have
greater than 100MB of data to write before I finally start actually moving some
data to disk?
> This is due to this smarter handling of the flushing of
> dirty pages and due to a more subtle bug where the system
> ended up doing synchronous IO on too many pages, whereas
> now it only does synchronous IO on _1_ page per scan ;)
And this is definately a noticeable fix, thanks for your continued work. I know
it's hard to get everything balanced out right, and I only wrote this email to
describe some behavior I was seeing and make sure it was expected in the current
VM. You've let me know that it is, and it's really minor compared to problems
some of the earlier kernels had.
Later,
Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/