On Tue, 6 Feb 2007, Joel Becker wrote: > On Tue, Feb 06, 2007 at 03:56:14PM -0800, Davide Libenzi wrote: > > Async syscall submissions are a _one time_ things. It's not like a live fd > > that you can push inside epoll and avoid the multiple O(N) passes. > > First of all, the amount of syscalls that you'd submit in a vectored way > > are limited. They do not depend on the total number of connections, but on > > I regularly see apps that want to submit 1000 I/Os at once. > Every submit. But it's all against one or two file descriptors. So, if > you return to userspace, they have to walk all 1000 async_results every > time, just to see which completed and which didn't. And *then* go wait > for the ones that didn't. If they just wait for them all, they aren't > spinning cpu on the -EASYNC operations. > I'm not saying that "don't return a completion if we can > non-block it" is inherently wrong or not a good idea. I'm saying that > we need a way to flag them efficiently.
To how many "sessions" those 1000 *parallel* I/O operations refer to? Because, if you batch them in an async fashion, they have to be parallel. Without the per-async operation status code, you'll need to wait a result *for each* submitted syscall, even the ones that completed syncronously. Open questions are: - Is the 1000 *parallel* syscall vectored submission case common? - Is it more expensive to forcibly have to wait and fetch a result even for in-cache syscalls, or it's faster to walk the submission array? - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
