Re: [PATCH 0 of 4] Generic AIO by scheduling stacks

[Davide Libenzi <davidel@xmailserver.org>]

On Fri, 9 Feb 2007, Linus Torvalds wrote:

> > Another, even simpler way IMO, is to just have a plain per-task kthread 
> > pool, and a queue.
> 
> Yes, that is actually quite doable with basically the same interface. It's 
> literally a "small decision" inside of "schedule_async()" on how it 
> actually would want to handle the case of "hey, we now have concurrent 
> work to be done".

For the queue approach, I meant the async_submit() to simply add the 
request (cookie, syscall number and params) inside queue, and not trying 
to execute the syscall. Once you're inside schedule, "stuff" has already 
partially happened, and you cannot have the same request re-initiated by a 
different thread.



> But I actually don't think a per-task kthread pool is necessarily a good 
> idea. If a thread pool works for this, then it should have worked for 
> regular thread create/destroy loads too - ie there really is little reason 
> to special-case the "async system call" case.

A per-process thread pool already has things correctly inherited, so we 
don't need to add special "adopt" routines for things like "files" and such.



> NOTE! I'm also not at all sure that we actually want to waste real threads 
> on this. My patch is in no way meant to be an "exclusive alternative" to 
> fibrils. Quite the reverse, actually: I _like_ those synchronous fibrils, 
> but I didn't like how Zach did the overhead of creating them up-front, 
> because I really would like the cached case to be totally *synchronous*.

I'm not advocating threads against fibrils. The use of threads may make 
things easier under certain POVs (less ad-hoc changes into mainline). The 
ideal would be to have a look at both and see Pros&Cons under different 
POVs (performance, code impact, etc..).



- Davide