On Aug 2, 8:43am, Andrea Arcangeli wrote:
>
> OTOH I'm a little biased in the above reasoning since I use the kiobuf
> only for doing direct I/O (I always end calling brw_kiovec somehow,
> otherwise I wouldn't be using the kiobufs at all). If you are using the
> kiobufs for framebuffers and other drivers that never ends calling
> brw_kiovec I think you should be using the mmap callback and
By "mmap callback", you're referring to the mmap entry in the file_operations
structure?
> remap_page_range instead as most drivers correctly do to avoid the
> overhead of the kiobufs. But ok if you really want to use the kiobuf for
> non I/O things instead of remap_page_range (dunno why) we could split
> off the bh-array allocation from the kiobuf to make it a bit lighter so
> you could use it for non-IO operations without the overhead of the bhs,
> but still we should adapt rawio to preallocate the bh at open/close time
> (separately from the kiovec).
>
> Andrea
I am doing direct I/O. I'm using the kiobuf to hold the page addresses
of the user's data buffer, but I'm calling directly into my driver
after doing the map_user_kiobuf() (I have a read/write request, a file
offset, a byte count, and a set of pages to DMA into/out of, and that
gets directly translated into a SCSI command).
It turns out that the old kmem_cache_alloc was very lightweight, so I
could get away with doing it once per I/O request, so I would indeed
profit by going back to a light weight kiobuf, or at least an optional
allocation of the bh and blocks arrays (perhaps turn them into pointers
to arrays?).
thanks
jeremy
-
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 : Tue Aug 07 2001 - 21:00:17 EST