Re: [PATCH] dio: Fast-path for page-aligned IOs
From: Andi Kleen
Date: Tue Jun 21 2011 - 17:44:19 EST
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@xxxxxxxxxxxxxx> wrote:
> > Dan Ehrenberg <dehrenberg@xxxxxxxxxx> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/