On Tue, Oct 25, 2016 at 07:31:56AM -0800, Kent Overstreet wrote: > So you're still walking the mappings, then for each mapping allocating a bio and > pinning pages - opposite of my approach, I started out by allocating a bio and > pinning pages and then walk the mapping, splitting the bio as needed. > > I still like my approach better, I think it ought to perform better when doing > fragmented IOs and it feels cleaner to me - you're not going back and forth > between calling into the gup() code, and your filesystem's btree code, both of > which are going to require taking their own set of locks and such. That said, I > doubt it's much of a difference and your code is so much simpler than > direct-IO.c that who cares :) Yes, this is the basic idea behind the whole iomap code - we have a generic apply function that calls into the fs allocator, and then takes a callback that it applies to one extent at a time. It really helps a lot to separate responsibilities and factor the code into independent functions. I looked at carrying over bios between different invocations of the callback, but it quickly turned into a mess. In the end the only thing we'd optimize with it is the gup call - bios would have to be split anyway, etc, etc. So with this code there indeed is a worsr case for badly fragmented files, but I'd rather work on the fs allocator to further reduce the amount of fragmentation we have rather than working around it. E.g. for XFS Darrick and I have sketched a rough plan for an auto-COW mode where we'd simply not reuse fragmented blocks for an overwrite and will instead give the caller a nice contiguous single extent. > Do you have your code up in a git repo somewhere? I'm going to compare it to > bcachefs's dio code and see if I can remember all edge cases I hit when I was > working on that. Git: git://git.infradead.org/users/hch/vfs.git iomap-dio Gitweb: http://git.infradead.org/users/hch/vfs.git/shortlog/refs/heads/iomap-dio -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
