changes to kiobuf support in 2.4.(?)4
Quoted 13 lines · Andrea Arcangeli
Quoted 7 lines
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).Quoted 5 lines
It turns out that the old
kmem_cache_allocwas 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?).
Quoted 6 lines
I see your problem and it's a valid point indeed. But could you actually allocate the kiobuf in the
file->f_iobufpointer? I mean: could you allocate it at open/close too? That would be the way I prefer since you would need to allocate the bh anyways later (but with a flood of alloc/free). So if you could move the kiobufs allocation out of the fast path you would get a benefit too I believe.
I have two answers to this.
The first is that I don't need the bh's or block's in my implementation. Everything I need is in the old-style kiobuf or is passed as an argument.
The second is I don't see a file->f_iobuf pointer in my source tree, which is 2.4.8-pre3, I believe. In fact, the kiobuf pointer is stored in the raw_devices array in my version of raw.c, and there is only one per raw device.
Assuming I'm out of date, and there is some way to store a kiobuf pointer into the file data structure, and I'll never see two requests outstanding at the same time to the same file, then I could do as you suggest. I'd be wasting about 16KB per open file (assuming 512KB and 64 bit) and adding unneeded CPU overhead at open time, but I could live with that.
Quoted 1 line
Andrea
thanks
jeremy