]> git.neil.brown.name Git - history.git/commit
[PATCH] direct-to-BIO for O_DIRECT
authorAndrew Morton <akpm@zip.com.au>
Sun, 14 Jul 2002 10:24:40 +0000 (03:24 -0700)
committerLinus Torvalds <torvalds@home.transmeta.com>
Sun, 14 Jul 2002 10:24:40 +0000 (03:24 -0700)
commit42ec8bc1d0bd11f0ebcb05c4c4a02065c08f4e73
treec08d69e317566c25880498c36b072a54c1927eff
parent2dbd15029c00ec56983a240a98306e8ea4101baa
[PATCH] direct-to-BIO for O_DIRECT

Here's a patch which converts O_DIRECT to go direct-to-BIO, bypassing
the kiovec layer.  It's followed by a patch which converts the raw
driver to use the O_DIRECT engine.

CPU utilisation is about the same as the kiovec-based implementation.
Read and write bandwidth are the same too, for 128k chunks.   But with
one megabyte chunks, this implementation is 20% faster at writing.

I assume this is because the kiobuf-based implementation has to stop
and wait for each 128k chunk, whereas this code streams the entire
request, regardless of its size.

This is with a single (oldish) scsi disk on aic7xxx.  I'd expect the
margin to widen on higher-end hardware which likes to have more
requests in flight.

Question is: what do we want to do with this sucker?  These are the
remaining users of kiovecs:

drivers/md/lvm-snap.c
drivers/media/video/video-buf.c
drivers/mtd/devices/blkmtd.c
drivers/scsi/sg.c

the video and mtd drivers seems to be fairly easy to de-kiobufize.
I'm aware of one proprietary driver which uses kiobufs.  XFS uses
kiobufs a little bit - just to map the pages.

So with a bit of effort and maintainer-irritation, we can extract
the kiobuf layer from the kernel.
drivers/char/raw.c
fs/Makefile
fs/block_dev.c
fs/buffer.c
fs/direct-io.c [new file with mode: 0644]
fs/ext2/inode.c
include/linux/buffer_head.h
include/linux/fs.h
mm/filemap.c