direct-to-BIO for O_DIRECT
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Andrew Morton
drivers/md/lvm-snap.c
drivers/media/video/video-buf.c
drivers/mtd/devices/blkmtd.c
drivers/scsi/sg.cthe 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.
lkcd uses it too for its kernel crash dump. I suspect it wouldn't be that hard to change.
Quoted 4 lines
So with a bit of effort and maintainer-irritation, we can extract the kiobuf layer from the kernel.
Do we want to do that?
I think yes - keeping two kinds of iovectors for IO (kiovecs and BIOs) seems to be redundant.
kiovecs never fulfilled their original promise of a universal zero copy container (e.g. they were too heavy weight for networking) so it's probably best to remove them as a failed experiment.
-Andi
Quoted 7 lines · Andi Kleen
Quoted 5 lines · Andrew Morton
drivers/md/lvm-snap.c
drivers/media/video/video-buf.c
drivers/mtd/devices/blkmtd.c
drivers/scsi/sg.c
Quoted 6 lines
Quoted 3 lines
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.
lkcd uses it too for its kernel crash dump. I suspect it wouldn't be that hard to change.
No, it shouldn't be hard to change. In fact, we've had to think of changing it for 2.5 anyhow, since most likely we can't afford bio alloc's happening under the covers down that path.
Quoted 4 lines
Quoted 4 lines
So with a bit of effort and maintainer-irritation, we can extract the kiobuf layer from the kernel.
Quoted 8 lines
Quoted 1 line
Do we want to do that?
I think yes - keeping two kinds of iovectors for IO (kiovecs and BIOs) seems to be redundant.
kiovecs never fulfilled their original promise of a universal zero copy container (e.g. they were too heavy weight for networking) so it's probably best to remove them as a failed experiment.
Yes, I think Kiobufs can go, and we can use something like kvecs (from aio code base) instead which are better for representing readv/writev, for the generic case (i.e. when its not just for block i/o). Its easy enough to map kvecs into bio s or zero-copy networking.
Regards
Suparna
Quoted 6 lines
(quoted diff) +0
-2-Andi -To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines · Andi Kleen
Quoted 5 lines · Andrew Morton
drivers/md/lvm-snap.c
drivers/media/video/video-buf.c
drivers/mtd/devices/blkmtd.c
drivers/scsi/sg.c
Quoted 7 lines
Quoted 3 lines
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.
lkcd uses it too for its kernel crash dump. I suspect it wouldn't be that hard to change.
We can remove their use from our 2.5 tree. Not a problem, as there are other ways to accomplish what we want.
Quoted 1 line
-Andi
--Matt