Re: [PATCH] dio: Fast-path for page-aligned IOs

[Andi Kleen <andi@firstfloor.org>]

On Tue, Jun 21, 2011 at 02:21:48PM -0700, Daniel Ehrenberg wrote:
> On Tue, Jun 21, 2011 at 1:41 PM, Andi Kleen <andi@firstfloor.org> wrote:
> > Dan Ehrenberg <dehrenberg@google.com> writes:
> >
> >> This code introduces a fast-path variant of __blockdev_direct_IO
> >> for the special case where the request size is a multiple of the page
> >> size, the inode block size is a page, the user memory is page-aligned,
> >> the underlying storage is contiguous on disk and the file location is
> >> already initialized. The special case decreases the amount of
> >> bookkeeping required, which saves a significant amount of CPU time on
> >> a fast device such as a ramdisk or an SSD.  The patch is inspired by
> >> earlier code by Ken Chen.
> >
> > Is it understood why your fast path is that much faster?
> > i.e. what's the slow part in the normal path that it avoids?
> >
> > I am wondering if some of the improvements could be gotten even for less
> > rigid pre conditions.
> 
> I should start by saying that I really should've submitted this with
> an [RFC] tag. I'm eager for feedback on my first Linux kernel patch,
> and I'm really glad you responded.
> 
> The slowness in the dio code that I have observed is not in any
> particular place, but rather a death of a thousand cuts. Lines like
>         memset(dio, 0, offsetof(struct dio, pages));

Hmm, is it cache miss stalls or just core cycles? 

If the later I assume gcc generated an slow out of line call
for memset.  I guess that would be fixable.

If the former maybe need a strategic prefetch?

Possibly a slab constructor would also help and avoid some of the 
reinitialization costs (this would requirement a fixed size
limit for the fast path, but I guess that's reasonable)

> show up as significant in the CPU profile, but so do other random
> lines that manipulate the struct dio.

That would suggest cache misses?

So why does your version avoid those?

> You're right that these preconditions are rather rigid, though. If you
> have a suggestion for a more general precondition, I can try it out
> and see if it maintains the performance properties I want.

Not fully sure, but I would be interested in support for 512 byte sectors
at least.

-Andi