> Looks like I've been missing an interesting thread here ....
Hi Steve ;-)
>
> Surely flushing pages (and hence cleaning them) is not a bad thing to
> do, provided you do not suck up all the available I/O bandwidth in the
> process. The filesystem decides to clean the pages as it is efficient
> from an I/O point of view. The vm is then free to reuse lots of pages
> it could not before, but it still gets to make the decision about the
> pages being good ones to reuse.
Very true, there are a few different workloads to consider.
1) The box really needs ram right now, and we should do the minimum amount
of work to get it done. This is usually done by kswapd or a process doing
an allocation. It should help if the FS gives the VM enough details to
skip pages that require extra allocations (like commit blocks) in favor of
less expensive ones.
2) There's lots of dirty pages around, it would be a good idea to flush
some, regardless of how many pages might be freeable afterwards. This is
where we want most of the i/o to actually happen, and where we want to give
the FS the most freedom in regards to which pages get written.
>
> The xfs kernel changes add a call to writepage into the buffer flushing
> path when the data is delayed allocate. We then end up issuing I/O on
> surrounding pages which end up being contiguous on disk and are not
> currently locked by some other thread.
This probably helps in both situations listed, assuming things like HIGHMEM
bounce buffers don't come into play.
-chris
-
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/