Messages in this thread | | | From | Zach Brown <> | Subject | Re: [PATCH 0 of 4] Generic AIO by scheduling stacks | Date | Tue, 30 Jan 2007 14:40:49 -0800 |
| |
> I looked at this approach a long time ago, and basically gave up > because > it looked like too much work.
Indeed, your mention of it in that thread.. a year ago?.. is what got this notion sitting in the back of my head. I didn't like it at first, but it grew on me.
> I heartily approve, although I only gave the actual patches a very > cursory > glance. I think the approach is the proper one, but the devil is in > the > details. It might be that the stack allocation overhead or some other > subtle fundamental problem ends up making this impractical in the > end, but > I would _really_ like for this to basically go in.
As for efficiency and overhead, I hope to get some time with the team that work on the Giant Database Software Whose Name We Shall Not Speak. That'll give us some non-trival loads to profile.
> It won't matter at all for a certain class of calls (a lot of the > people > who want to do AIO really end up doing non-interruptible things, and > signalling is a non-issue), but not only is it going to matter for > some > others, we will almost certainly want to have a way to not just > signal a > task, but a single "fibril" (and let me say that I'm not convinced > about > your naming, but I don't hate it either ;)
Yeah, no doubt. I'm wildly open to discussion here. (and yeah, me either, but I don't care much about the name. I got tired of qualifying overloaded uses of 'stack' or 'thread', that's all :)).
> But from a quick overview of the patches, I really don't see anything > fundamentally wrong. It needs some error checking and some limiting (I > _really_ don't think we want a regular user starting a thousand > fibrils > concurrently), but it actually looks much less invasive than I > thought it > would be.
I think we'll also want to flesh out the submission and completion interface so that we don't find ourselves frustrated with it in another 5 years. What's there now is just scaffolding to support the interesting kernel-internal part. No doubt the kevent thread will come into play here.
- 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/
| |