On Mon, 08 Jul 2002 13:00:12 +0530, Andi Kleen wrote:
> Andrew Morton <akpm@zip.com.au> writes:
>
>> 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.
>
> 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.
>
>> 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.
>
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
> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majordomo@vger.kernel.org More majordomo
> info at http://vger.kernel.org/majordomo-info.html Please read the FAQ
> at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:12 EST