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-kern
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
> 
>