On Tue, Feb 04, 2014 at 09:35:06AM -0800, Kent Overstreet wrote: > > I think Kent is talking about what happens after the user addresses are > > consumed. Turning dio into more of a bio mapping and redirection engine > > would use more of the bio machinery instead of the bits that dio has > > implemented itself with state in struct dio that hangs off the bios. I > > imagine it'd still make sense to clean up the addresses/pages arguments > > that feed that engine. (And give another entry point that already has > > bios for callers like loop, etc.) > > Yeah, precisely. I think we can push the point at which pages are pinned at > least a fair but higher than it is now, and if we can do that we definitely > should be working with a generic "bag of pinned pages" struct - and much > better to use struct bio than add another one. Bios may not be perfect but > at least some of the block layer specific cruft can be gotten rid of (and > is on my todo list) How far up? I've no problem with having that done in ->direct_IO() (especially if it would take this mem_vec/mem_stream/whatever and keep the code doing actual pinning and building an array of pages outside of direct-io.c, allowing it to do different things for iovec-backed and page-array-backed variants), but I really don't like the idea of lifting that to callers of ->direct_IO(), let alone past them. If nothing else, we do *not* want to pin the entire write request, so lifting that to e.g. generic_file_aio_write() (or, worse, its callers) wouldn't make sense. -- 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
