Messages in this thread | | | From | Zach Brown <> | Subject | Re: [PATCH 0 of 4] Generic AIO by scheduling stacks | Date | Tue, 30 Jan 2007 14:53:18 -0800 |
| |
> So we should limit these to basically have some maximum concurrency > factor, but rather than consider it an error to go over it, we'd > just cap > the concurrency by default, so that people can freely use asynchronous > interfaces without having to always worry about what happens if their > resources run out..
Yeah, call it the socket transmit queue model :). Maybe tuned by a ulimit?
I don't have very strong opinions abou the specific mechanics of limiting concurrent submissions, as long as they're there. Some folks in Oracle complain about having one more thing to have to tune, but the alternative seems worse.
> However, that also implies that we should probably add a "flags" > parameter > to "async_submit()" and have a FIBRIL_IMMEDIATE flag (or a timeout) or > something to tell the kernel to rather return EAGAIN than wait. > Sometimes > you don't want to block just because you already have too much work.
EAGAIN or the initial number of submissions completed before the one that ran over the limit, perhaps. Sure. Nothing too controversial here :). I have this kind of stuff queued up for worrying about once the internal mechanics are stronger.
- z
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |