In message <20050301103057.GE10259@spathi.chuq.com>Chuck Silvers writes
>On Mon, Feb 28, 2005 at 02:24:35PM -0800, Jonathan Stone wrote:

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

I think you misunderstand my point. FreeBDS performs well on this
benchmark. NetBSD, with a similar filesystem, performs very poorly. Why?

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

Forgive me repeating the question, but: since FreeBSD does so much
better on this benchmark, do we know what FreeBSD does differently?
E.g., does mysql on FreeBSD automagically use O_DIRECT (with
concurrent reads and writes?) or does it exercise a completely
different codepath?