On Wed, May 22, 2019 at 07:12:14AM +0200, Christoph Hellwig wrote: > On Wed, May 22, 2019 at 08:24:34AM +1000, Dave Chinner wrote: > > Yeah, the log recovery code should probably be split in three - the > > kernel specific IO code/API, the log parsing code (the bit that > > finds head/tail and parses it into transactions for recovery) and > > then the bit that actually does the recovery. THe logprint code in > > userspace uses the parsing code, so that's the bit we need to share > > with userspace... > > Actually one thing I have on my TODO list is to move the log item type > specific recovery code first into an ops vector, and then out to the > xfs_*_item.c together with the code creating those items. That isn't > really all of the recovery code, but it seems like a useful split. Sounds like the right place to me - it's roughly where I had in mind to split the code as it's not until logprint decodes the transactions and needs to parse the individual log items that it diverges from the kernel code. So just having a set of op vectors that we can supply from userspace to implement logprint would make it much simpler.... > Note that the I/O code isn't really very log specific, it basically > just is trivial I/O to a vmalloc buffer code. In fact I wonder if > I could just generalize it a little more and move it to the block layer. Yeah, it's not complex, just different to userspace. Which is why I thought just having a simple API to between it and the kernel log code would make it easy to port... > > I've got a rough AIO implementation backing the xfs_buf.c code in > > userspace already. It works just fine and is massively faster than > > the existing code on SSDs, so I don't see a problem with porting IO > > code that assumes an AIO model anymore. i.e. Re-using the kernel AIO > > model for all the buffer code in userspace is one of the reasons I'm > > porting xfs-buf.c to userspace. > > Given that we: > > a) do direct I/O everywhere > b) tend to do it on either a block device, or a file where we don't > need to allocate over holes > > aio should be a win everywhere. So far it is, but I haven't tested on spinning disks so I can't say for certain that it is a win there. The biggest difference for SSDs is that we completely bypass the prefetching code and so the buffer cache memory footprint goes way down. Hence we save huge amounts of CPU by avoiding allocating, freeing and faulting in memory so we essentially stop bashing on and being limited by mmap_sem contention. > The only caveat is that CONFG_AIO > is kernel option and could be turned off in some low end configs. Should be trivial to add a configure option to turn it off and have the IO code just call pread/pwrite directly and run the completions synchronously. That's kind of how I'm building up the patchset, anyway - AIO doesn't come along until after the xfs_buf.c infrastructure is in place doing sync IO. I'll make a note to add a --disable-aio config option when I get there.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
