Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support

[Davide Libenzi <davidel@xmailserver.org>]

On Tue, 13 Feb 2007, Ingo Molnar wrote:

> I'm pleased to announce the first release of the "Syslet" kernel feature 
> and kernel subsystem, which provides generic asynchrous system call 
> support:
> [...]

Ok, I had little to time review the code, but it has been a long 
working day, so bear with me if I missed something.
I don't see how sys_async_exec would not block, based on your patches. 
Let's try to follow:

- We enter sys_async_exec

- We may fill the pool, but that's nothing interesting ATM. A bunch of 
  threads will be created, and they'll end up sleeping inside the 
  cachemiss_loop

- We set the async_ready pointer and we fall inside exec_atom

- There we copy the atom (nothing interesting from a scheduling POV) and 
  we fall inside __exec_atom

- In __exec_atom we do the actual syscall call. Note that we're still the 
  task/thread that called sys_async_exec

- So we enter the syscall, and now we end up in schedule because we're 
  just unlucky

- We notice that the async_ready pointer is not NULL, and we call 
  __async_schedule

- Finally we're in pick_new_async_thread and we pick one of the ready 
  threads sleeping in cachemiss_loop

- We copy the pt_regs to the newly picked-up thread, we set its async head 
  pointer, we set the current task async_ready pointer to NULL, we 
  re-initialize the async_thread structure (the old async_ready), and we 
  put ourselves in the busy_list

- Then we roll back to the schedule that started everything, and being 
  still "prev" for the scheduler, we go to sleep

So the sys_async_exec task is going to block. Now, am I being really 
tired, or the cachemiss fast return is simply not there?
There's another problem AFAICS:

- We woke up one of the cachemiss_loop threads in pick_new_async_thread

- The threads wakes up, mark itself as busy, and look at the ->work 
  pointer hoping to find something to work on

But we never set that pointer to a userspace atom AFAICS. Me blind? :)




- Davide


-
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/