[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [PATCH 5/5] aio: Refactor aio_read_evt, use cmxchg(), fix bug
- From: Zach Brown <zab redhat com>
- To: Kent Overstreet <koverstreet google com>
- Cc: linux-bcache vger kernel org, tytso mit edu, linux-kernel vger kernel org, dm-devel redhat com
- Subject: Re: [dm-devel] [PATCH 5/5] aio: Refactor aio_read_evt, use cmxchg(), fix bug
- Date: Tue, 9 Oct 2012 17:26:34 -0700
> The AIO ringbuffer stuff just annoys me more than most
Not more than everyone, though, I can personally promise you that :).
> (it wasn't until
> the other day that I realized it was actually exported to userspace...
> what led to figuring that out was noticing aio_context_t was a ulong,
> and got truncated to 32 bits with a 32 bit program running on a 64 bit
> kernel. I'd been horribly misled by the code comments and the lack of
> documentation.)
Yeah. It's the userspace address of the mmaped ring. This has annoyed
the process migration people who can't recreate the context in a new
kernel because there's no userspace interface to specify creation of a
context at a specific address.
> But if we do have an explicit handle, I don't see why it shouldn't be a
> file descriptor.
Because they're expensive to create and destroy when compared to a
single system call. Imagine that we're using waiting for a single
completion to implement a cheap one-off sync call. Imagine it's a
buffered op which happens to hit the cache and is really quick.
(And they're annoying to manage: libraries and O_CLOEXEC, running into
fd/file limit tunables, bleh.)
If the 'completion context' is no more than a structure in userspace
memory then a lot of stuff just works. Tasks can share it amongst
themselves as they see fit. A trivial one-off sync call can just dump
it on the stack and point to it. It doesn't have to be specifically
torn down on task exit.
> > And perhaps obviously, I'd start with the acall stuff :). It was a lot
> > lighter. We could talk about how to make it extensible without going
> > all the way to the generic packed variable size duplicating or not and
> > returning or not or.. attributes :).
>
> Link? I haven't heard of acall before.
I linked to it after that giant silly comment earlier in the thread,
here it is again:
http://lwn.net/Articles/316806/
There's a mostly embarassing video of a jetlagged me giving that talk at
LCA kicking around.. ah, here:
http://mirror.linux.org.au/pub/linux.conf.au/2009/Thursday/131.ogg
- z
- References:
- [dm-devel] [PATCH 1/5] aio: Kill return value of aio_complete()
- [dm-devel] [PATCH 5/5] aio: Refactor aio_read_evt, use cmxchg(), fix bug
- Re: [dm-devel] [PATCH 5/5] aio: Refactor aio_read_evt, use cmxchg(), fix bug
- Re: [dm-devel] [PATCH 5/5] aio: Refactor aio_read_evt, use cmxchg(), fix bug
- Re: [dm-devel] [PATCH 5/5] aio: Refactor aio_read_evt, use cmxchg(), fix bug
- Re: [dm-devel] [PATCH 5/5] aio: Refactor aio_read_evt, use cmxchg(), fix bug
- Re: [dm-devel] [PATCH 5/5] aio: Refactor aio_read_evt, use cmxchg(), fix bug
- Re: [dm-devel] [PATCH 5/5] aio: Refactor aio_read_evt, use cmxchg(), fix bug
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]