Subject: Re: Coallesce disk I/O (was RE: Interactive responsiveness under
To: Gordon Waidhofer <gww@traakan.com>
From: Stephan Uphoff <ups@tree.com>
List: tech-perform
Date: 01/26/2004 18:52:37
>
> Disk I/O performance can be **dramatically** improved
> by I/O coallescing. My experience with a proprietary
> operating system proved this many times over. Linux
> coallesces disk I/Os.
I agree - really useful for a filesystem log and small nfs type write requests.
When I initially wrote the file system for Network Storage Solution
they had a proprietary kernel and I could use scatter/gather for
I/O coalescing.
Porting to NetBSD we had Chris Jepeway implement clustering using
(architecture specific)
MMU tricks.
NSS allowed Chris Jepeway to post some of the clustering code.
http://mail-index.netbsd.org/tech-perform/2002/09/07/0000.html
However since the code only works on i386 (and probably a few other
architectures)
interest in the code was low.
Chris was busy with other work and never got around to make it arch
independent.
Stephan
>
> When there are multiple bufs (struct bufs) on the
> disk queue doing the same command (read/write) and
> accessing consecutive disk addresses, the bufs are
> turned into one I/O and use scatter/gather. Error
> recovery amounts to bursting the chain and retrying
> the bufs individually. It works best if I/Os can be
> scheduled in batches, ala strategy_list(bp) rather
> than one at a time ala strategy(bp).
>
> There was a reference in the "LFS on BSD" paper
> (Seltzer, et al) to a Berkeley project around
> the same time that added I/O coallescing to
> stock FFS. The performance rivaled LFS. I've
> never been able to find a paper on that project.
> Anybody know more?
>
> Is anybody working on coallesced disk I/Os?
>
> I've only given it a cursory look. I want
> to find a way to add coallescing without
> tearing-up the whole struct buf subsystem.
> It works best if done very near the device
> driver. I'm hoping to find a way for the
> device drivers to do some sort of "just in time"
> coallescing. That way, the struct bufs and
> queues would be fine the way they are.
> No new data structures need be added or maintained.
> It'll be the later part of the year before
> I can really wade in.
>
> -gww
>
>