On Sat, Feb 06, 2010 at 09:14:53AM -0500, Ted Unangst wrote:
> On Sat, Feb 6, 2010 at 8:44 AM, Mark Kettenis <mark.kette...@xs4all.nl> wrote:
> >> > Continuing in my "make IO suck less" phase, cp would be a lot more
> >> > efficient if it didn't bounce the disk heads around so much. ?Instead of
> >> > using a tiny 64k buffer, use an amount based on a small fraction of RAM.
> >>
> >> Isn't it the task of the buffer cache to optimize memory use here?
> >
> > Exactly the point I was just about to raise.
>
> Optimizing memory has nothing to do with it. The buffer cache doesn't
> do a whole lot to reduce seeking. This is what cp looks like:
>
> read .000001s
> seek .001s
> write .000001s
> seek .001s
> read .000001s
> seek .001s
>
> It doesn't matter if the buffer cache does readahead, it never reads
> enough ahead. It doesn't matter if the buffer cache is write back,
> the writes are still in the queue, and the elevator still goes. If
> you were moving from the 10th floor to the 90th floor, would you take
> the boxes up one at a time?
The buffer cache should ne smart enough to optmize read and writes in
such large chunks so that the seeking gets reduced. The problem with
your big buffers is that you are claiming resources even if you have
no idea if they are available or not.
-Otto
