Messages in this thread | | | Date | Mon, 27 Feb 2012 16:53:09 -0600 | From | Dave Kleikamp <> | Subject | Re: [RFC PATCH 00/22] loop: Issue O_DIRECT aio with pages |
| |
On 02/27/2012 04:27 PM, Zach Brown wrote: > On 02/27/2012 04:19 PM, Dave Kleikamp wrote: >> This patchset was begun by Zach Brown and was originally submitted for >> review in October, 2009. > > Man, it's been a while. I remembered almost none of the details of this > work when I read your introductory message. As I read the patches it > all came flooding back, though. Yikes :). > > My biggest fear about this patch series is the sheer amount of very > fiddly code motion. I remember spending a lot of time verifying that > the patches didn't accidentally lose new changes as the patches were > ported to newer kernels. > > Has someone gone through these most recent patches with an absurdly fine > toothed comb? The patches that touch fs/direct-io.c and mm/filemap.c > are the most risky, by far.
I was pretty careful porting these patches, trying not to lose the effects of any newer changes to the affected functions. It wouldn't hurt to go through them again, but I am putting it out as an RFC since I don't think these are ready to merge quite yet.
>> This series was written to reduce the current overhead loop imposes by >> performing synchronus buffered file system IO from a kernel thread. >> These >> patches turn loop into a light weight layer that translates bios into >> iocbs. > > It'd be worth including some simple benchmark results, I think. I > remember testing with concurrent O_DIRECT aio with fio on a loopback > device on top of files in each underlying file system.
Actually, some preliminary tests I ran showed a significant slowdown. I suspect it may have to do with the unconditional setting of O_DIRECT, but I haven't verified that yet. I'll do further performance analysis, but I wanted to get some eyes on this in the mean time.
Thanks, Shaggy
| |