changes to kiobuf support in 2.4.(?)4
Quoted 6 lines · Andrea Arcangeli
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_kiovecsomehow, otherwise I wouldn't be using the kiobufs at all). If you are using the kiobufs for framebuffers and other drivers that never ends callingbrw_kiovecI think you should be using the mmap callback and
By "mmap callback", you're referring to the mmap entry in the file_operations structure?
Quoted 9 lines
remap_page_rangeinstead 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 ofremap_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