On Tue, Feb 5, 2013 at 4:40 PM, Joel Becker <jlbec@xxxxxxxxxxxx> wrote: > I vote for trying the helper approach. I think dropping generic > code altogether would be a disaster. The corner cases of O_DIRECT are > legion; everyone has behavioral assumptions based on historical > implementations, etc. Remember how badly some high-performance software > handles O_DIRECT alignments larger than 512B. > We have a long history of successfully inverting the generic > code with helpers and (if necessary, I'm not saying it is) operations > structures. > I don't think I'd try to shove down generic_aio_read/write. Let > them handle the check for O_DIRECT and the fallback to buffered I/O. Tackling the dio code has been high on my list, if I ever get time - in the profiles I've been doing, reading from a raw block device, the dio code is the biggest single source of overhead by a good margin and there's plenty of obvious inefficiency. The helper approach was more or less what I had in mind - also, splitting out the block device path out to start with, and once that's cleaned up using that to guide how the helpers and such should be structured. The other thing that really frustrates me about the dio code is the perverse flow of control between the generic code and the fs code, via the getblk callbacks. IMO, it'd be much cleaner to aim for something more like submitting a bio to the block layer - just set up a bio, point it at inode:offset and pass it off to the fs code. If I can finish off my immutable bvec/efficient bio splitting code and get it in it should make that approach work out nicely. But currently my brain is stuffed full of other sutff :/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
