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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Jun 2011 23:44:13 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Daniel Ehrenberg <dehrenberg@...gle.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] dio: Fast-path for page-aligned IOs

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@...stfloor.org> wrote:
> > Dan Ehrenberg <dehrenberg@...gle.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/