On 06/14/2010 08:39 PM, Dave Chinner wrote:
On Mon, Jun 14, 2010 at 04:21:43PM -0700, Andrew Morton wrote:
But then, this all really should be done at the block layer so other
io-submitting-paths can benefit from it.
That was what we did in the past with really, really deep IO
scheduler queues. That leads to IO latency and OOM problems because
we could lock gigabytes of memory away under IO and take minutes to
clean it.
Besides, there really isn't the right context in the block layer to
be able to queue and prioritise large amounts of IO without
significant penalties to some higher layer operation.
Can we kick flushing for the whole inode at once from
vmscan.c?
That way we should:
1) ensure that the page we want is written to disk, and
2) we flush out related pages at the same time, getting
a decent IO pattern
Chances are that if we want to evict one page from a
file, we'll also want to evict other pages from that
same file. In fact, chances are a good number of them
will live nearby on the LRU list.
Does this make sense?
Would it be hard to add a "please flush this file"
way to call the filesystem flushing threads?
--
All rights reversed
--
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
