Subject: Re: direct I/O
To: Jonathan Stone <jonathan@dsg.stanford.edu>
From: Chuck Silvers <chuq@chuq.com>
List: tech-kern
Date: 03/01/2005 02:30:57
On Mon, Feb 28, 2005 at 02:24:35PM -0800, Jonathan Stone wrote:
> 
> In message <20050228081036.GA20462@spathi.chuq.com>,
> Chuck Silvers writes:
> 
> >hi folks,
> >
> >since my profiling experiments with the 10M Rows mysql benchmark showed that
> >avoiding read-before-overwrite didn't help much at all, this morning I decided
> >to go for the real solution and look into unbuffered (aka direct) I/O.
> >implementing this turned out to be much easier than I expected, it only
> >took a few hours to get it working.  the diff is at:
> >
> >	ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/diff.directio
> 
> I hate to seem nagging, and I do appreciate the performance regression
> tests you did with loanout.
> 
> But: if FreeBSD-4 doesn't need direct I/O, why do we need it?  Could

it's not a question of need, I'm saying that direct I/o should perform
better than buffered I/O (even with loaning) for database-style applications
that do their own caching.


> the poor performance be symptomatic of something else -- e.g., by
> analogy to the relative NFS performance of NetBSD-2.0 and Free-BSD4,
> maybe we just lack sufficient read-ahead?

there appear to be two problems with the netbsd in the default configuration
in the 10M Rows benchmark:

 - our default settings for memory-usage balancing cause mysql's cache to
   be paged out.
 - even with settings that prevent the mysql cache from being paged out,
   fsync() on a file with lots of pages in memory takes a lot of CPU time.

but even if both of these problems were solved, I think that using
direct I/O + concurrent I/O should give even better performance,
since with direct I/O there's less TLB frobbing and we never need
to copy the data because it's never shared in memory.


> Does your directio patch already show a big improvement in the 10M
> Rows mysql benchmark?

with just the direct I/O patch that I posted, one write() to a file will
block all other reads and writes to that file, so performance is actually
much worse than buffered.  that's why I talked about the additional work
of allowing concurrent reads and writes.  I haven't implemented the
concurrent part yet though.

-Chuck