Re: New AIO API
From: Andrew Morton
Date: Mon Apr 15 2013 - 18:31:34 EST
On Fri, 12 Apr 2013 15:28:56 -0700 Kent Overstreet <koverstreet@xxxxxxxxxx> wrote:
> So, awhile back I posted about an extensible AIO attributes mechanism
> I'd been cooking up: http://article.gmane.org/gmane.linux.kernel/1367969
> Since then, more uses for the thing have been popping up, but I ran into
> a roadblock - with the existing AIO api, return values for the
> attributes were going to be, at best, considerably uglier than I
> Some background: some attributes we'd like to implement need to be able
> to return values with the io_event at completion time. Many of the
> examples I know of are more or less tracing - returning how long the IO
> took, whether it was a cache hit or miss (bcache, perhaps page cache
> when buffered AIO is supported), etc.
> Additionally, you probably want to be able to return whether the
> attribute was supported/handled at all (because of differing kernel
> versions, or because it was driver specific) and we need attribute
> returns to be able to sanely handle that.
> So my opinion is that the only really sane way to implement attribute
> return values is to pass them back to userspace via the ringbuffer,
> along with the struct io_event.
> (For those not intimately familiar with the AIO implementation, on
> completion the generated io_event is copied into a ringbuffer which
> happens to be mapped into userspace, even though normally userspace will
> get the io_event with io_getevents(). This ringbuffer constrains the
> design quite a bit, though).
> Trouble is, we (probably, there is some debate) can't really just change
> the existing ringbuffer format - there's a version field in the existing
> ringbuffer, but userspace can't check that until after the ringbuffer is
> setup and mapped into userspace. There's no existing mechanism for
> userspace to specify flags or options or versioning when setting up the
> io context.
> So, to do this requires new syscalls, and more or less forking most of
> the existing AIO implementation. Also, returning variable length entries
> via the ringbuffer turns out to require redesigning a substantial
> fraction of the existing AIO implementation - so we might as well fix
> everything else that needs fixing at the same time.
This all sounds like a lot of work, risk, disruption, bloat, etc, etc.
That's not a problem per-se, but it should only be undertaken if the
payback makes it worthwhile.
Unfortunately your email contains only a terse description of this most
important factor: if we add all this stuff to Linux, what do we get in
return? "More or less tracing". Is that useful enough to justify the
changes? Please let's pay a lot more attention to this question before
getting further into implementation stuff! Sell it to us.
> Those are the main changes (besides adding attributes, of course) that
> I've made so far.
> * Get rid of the parallel syscall interface
> AIO really shouldn't be implementing its own slightly different
> syscalls; it should be a mechanism for doing syscalls asynchronously.
Yes. We got about a twelfth of the way there many years ago
(google("syslets")) but it died. A shame.
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/