* [ATTEND] Attendance request
@ 2012-02-02 16:51 Dave Kleikamp
2012-02-02 19:00 ` Zach Brown
2012-02-02 20:29 ` Ted Ts'o
0 siblings, 2 replies; 8+ messages in thread
From: Dave Kleikamp @ 2012-02-02 16:51 UTC (permalink / raw)
To: lsf-pc; +Cc: linux-fsdevel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ATTEND] Attendance request
2012-02-02 16:51 [ATTEND] Attendance request Dave Kleikamp
@ 2012-02-02 19:00 ` Zach Brown
2012-02-02 19:07 ` Dave Kleikamp
2012-02-02 20:29 ` Ted Ts'o
1 sibling, 1 reply; 8+ messages in thread
From: Zach Brown @ 2012-02-02 19:00 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: linux-fsdevel
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ATTEND] Attendance request
2012-02-02 19:00 ` Zach Brown
@ 2012-02-02 19:07 ` Dave Kleikamp
0 siblings, 0 replies; 8+ messages in thread
From: Dave Kleikamp @ 2012-02-02 19:07 UTC (permalink / raw)
To: Zach Brown; +Cc: linux-fsdevel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ATTEND] Attendance request
2012-02-02 16:51 [ATTEND] Attendance request Dave Kleikamp
2012-02-02 19:00 ` Zach Brown
@ 2012-02-02 20:29 ` Ted Ts'o
2012-02-02 20:51 ` Zach Brown
2012-02-03 2:20 ` Zheng Liu
1 sibling, 2 replies; 8+ messages in thread
From: Ted Ts'o @ 2012-02-02 20:29 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: lsf-pc, linux-fsdevel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ATTEND] Attendance request
2012-02-02 20:29 ` Ted Ts'o
@ 2012-02-02 20:51 ` Zach Brown
2012-02-02 20:58 ` Ted Ts'o
2012-02-03 2:20 ` Zheng Liu
1 sibling, 1 reply; 8+ messages in thread
From: Zach Brown @ 2012-02-02 20:51 UTC (permalink / raw)
To: Ted Ts'o; +Cc: Dave Kleikamp, linux-fsdevel
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ATTEND] Attendance request
2012-02-02 20:51 ` Zach Brown
@ 2012-02-02 20:58 ` Ted Ts'o
2012-02-02 21:03 ` Zach Brown
0 siblings, 1 reply; 8+ messages in thread
From: Ted Ts'o @ 2012-02-02 20:58 UTC (permalink / raw)
To: Zach Brown; +Cc: Dave Kleikamp, linux-fsdevel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ATTEND] Attendance request
2012-02-02 20:58 ` Ted Ts'o
@ 2012-02-02 21:03 ` Zach Brown
0 siblings, 0 replies; 8+ messages in thread
From: Zach Brown @ 2012-02-02 21:03 UTC (permalink / raw)
To: Ted Ts'o; +Cc: Dave Kleikamp, linux-fsdevel
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ATTEND] Attendance request
2012-02-02 20:29 ` Ted Ts'o
2012-02-02 20:51 ` Zach Brown
@ 2012-02-03 2:20 ` Zheng Liu
1 sibling, 0 replies; 8+ messages in thread
From: Zheng Liu @ 2012-02-03 2:20 UTC (permalink / raw)
To: Ted Ts'o; +Cc: Dave Kleikamp, lsf-pc, linux-fsdevel, Zach Brown
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-02-03 2:16 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-02 16:51 [ATTEND] Attendance request Dave Kleikamp
2012-02-02 19:00 ` Zach Brown
2012-02-02 19:07 ` Dave Kleikamp
2012-02-02 20:29 ` Ted Ts'o
2012-02-02 20:51 ` Zach Brown
2012-02-02 20:58 ` Ted Ts'o
2012-02-02 21:03 ` Zach Brown
2012-02-03 2:20 ` Zheng Liu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).