[ATTEND] Attendance request

[ATTEND] Attendance request

[Dave Kleikamp]

Committee members,

Please consider inviting me to the Storage, Filesystem, & MM Summit. I
am working in Chris Mason's team at Oracle focusing on storage I/O.

My latest focus is on completing the work started on by Zach Brown to
add a kernel interface to allow kernel code to submit aio, and having
the loop device submit direct IO requests to the underlying file system.

Zach's prototype:
http://kerneltrap.org/mailarchive/linux-fsdevel/2009/10/22/6516163

I should have patches ready for review within the next couple weeks.

Having gotten back into the filesystem/storage area after briefly
working the embedded world at IBM, I look forward to participating in
the summit and seeing everyone face-to-face again.

Thanks,
Dave "Shaggy" Kleikamp

Re: [ATTEND] Attendance request

[Zach Brown]

> My latest focus is on completing the work started on by Zach Brown to
> add a kernel interface to allow kernel code to submit aio, and having
> the loop device submit direct IO requests to the underlying file system.

You poor dear!

If you need any input, just holler.  I'm still around.

- z

Re: [ATTEND] Attendance request

[Dave Kleikamp]

On 02/02/2012 01:00 PM, Zach Brown wrote:
> 
>> My latest focus is on completing the work started on by Zach Brown to
>> add a kernel interface to allow kernel code to submit aio, and having
>> the loop device submit direct IO requests to the underlying file system.
> 
> You poor dear!
> 
> If you need any input, just holler.  I'm still around.

I'll certainly cc you when I have patches ready for review. Your patches
didn't suffer very much bit rot at all.

Thanks,
Shaggy

Re: [ATTEND] Attendance request

[Ted Ts'o]

On Thu, Feb 02, 2012 at 10:51:20AM -0600, Dave Kleikamp wrote:
> Committee members,
> 
> Please consider inviting me to the Storage, Filesystem, & MM Summit. I
> am working in Chris Mason's team at Oracle focusing on storage I/O.
> 
> My latest focus is on completing the work started on by Zach Brown to
> add a kernel interface to allow kernel code to submit aio, and having
> the loop device submit direct IO requests to the underlying file system.

We should talk; I'm currently working on an async bmap function for
ext4, which I then intended to use for a modified high-level AIO
support framework that allowed for async metadata access.  That is,
I'm interested in solving the "AIO isn't really 'A'" problem.

That's a different problem that what you're working on, but it's
obviously going to touch the same code.  (Actually, my original plan
was to not touch the generic code in __blockdev_direct_IO and below
and create some ext4-specific code for now, but if you're going to be
messing around in that code path anyway, we should coordinate....)

	       	       	    	 	 - Ted

Re: [ATTEND] Attendance request

[Zach Brown]

> We should talk; I'm currently working on an async bmap function for
> ext4, which I then intended to use for a modified high-level AIO
> support framework that allowed for async metadata access.  That is,
> I'm interested in solving the "AIO isn't really 'A'" problem.

Well, for that one blocking case in the submission path.

I certainly understand the desire to just make things less painful in
this case, but I do wonder if the long-term win is to sink resources
into trying to get threads executings async op so that the code paths
don't have to be butchered into state machines around each potential
blocking op.

It's a lot of work to get it transparent and efficient, I know.  But
then we'd be out of the business of obfuscating our code paths.

- z

Re: [ATTEND] Attendance request

[Ted Ts'o]

On Thu, Feb 02, 2012 at 03:51:03PM -0500, Zach Brown wrote:
> 
> Well, for that one blocking case in the submission path.
> 
> I certainly understand the desire to just make things less painful in
> this case, but I do wonder if the long-term win is to sink resources
> into trying to get threads executings async op so that the code paths
> don't have to be butchered into state machines around each potential
> blocking op.

I only intend to do this for reads and non-allocating writes; in those
cases, it's actually pretty easy.  And if everything is already in
cache, it's a lot easier to make things fast and not require diving
into workqueue or some other kernel thread.

My concern with just stuffing every single io_submit into a kernel
thread is the overhead involved, especially if there is a high rate of
AIO submission (think high-speed PCIe-attached flash).  Either you
will end up blocking waiting for a kernel thread to be available, or
you will burn a huge amount of kernel memory for the thread stacks if
nothing else.

						- Ted

Re: [ATTEND] Attendance request

[Zach Brown]

> I only intend to do this for reads and non-allocating writes; in those
> cases, it's actually pretty easy.

*nod*

> My concern with just stuffing every single io_submit into a kernel
> thread is the overhead involved, especially if there is a high rate of
> AIO submission (think high-speed PCIe-attached flash).

Oh, I certainly agree.  It'd be real work to find out if its possible to
make it perform reasonably.  I'd still like to see someone support that
work so I'll keep mentioning it :).

- z

Re: [ATTEND] Attendance request

[Zheng Liu]

On Thu, Feb 02, 2012 at 03:29:11PM -0500, Ted Ts'o wrote:
> On Thu, Feb 02, 2012 at 10:51:20AM -0600, Dave Kleikamp wrote:
> > Committee members,
> > 
> > Please consider inviting me to the Storage, Filesystem, & MM Summit. I
> > am working in Chris Mason's team at Oracle focusing on storage I/O.
> > 
> > My latest focus is on completing the work started on by Zach Brown to
> > add a kernel interface to allow kernel code to submit aio, and having
> > the loop device submit direct IO requests to the underlying file system.
> 
> We should talk; I'm currently working on an async bmap function for
> ext4, which I then intended to use for a modified high-level AIO
> support framework that allowed for async metadata access.  That is,
> I'm interested in solving the "AIO isn't really 'A'" problem.

Hi Ted,

Async metadata accessing is on our TODO list too. Would you like to
share more information to us? Maybe we can discuss this topic in ext4
developer's workshop. Thank you.

Regards,
Zheng

> 
> That's a different problem that what you're working on, but it's
> obviously going to touch the same code.  (Actually, my original plan
> was to not touch the generic code in __blockdev_direct_IO and below
> and create some ext4-specific code for now, but if you're going to be
> messing around in that code path anyway, we should coordinate....)
> 
> 	       	       	    	 	 - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html