Re: thread ids, task ids and subsystems

[Niels Möller]

Thanks for the excellent summary (in the other message). I have a few
questions and perhaps some answer, but I'll take it in separate
messages.

Marcus Brinkmann <address@hidden> writes:

> > (Either this, or the other extreme, let *every* hurdish port anywhere
> > in the system have one receiving thread per cpu).
> 
> Yes, that was the other solution that came into my mind, and in fact I think
> that this probably wouldn't be too bad at all.

I'm afraid there's something basic I'm missing here. Say client thread
A sends a request to server thread B. I'd expect the following to
happen:

1. At the start, A is executing on cpu 1, and thread B is sleeping in
   a blocking RPC receive call.

2. Then the RPC happens. A is put to sleep, and B is scheduled for
   execution.
 
   I'd expect L4 to schedule B on cpu 1, because (1) the thread that
   was running there was just put to sleep, so the cpu is free to
   take, and (2) the RPC arguments are located in *registers* inside
   cpu 1.

3. When B is finished, it replies and goes to sleep waiting for the
   next request (preferably by a *single* L4 RPC system call).

4. A is woken up, and again I'd expect it to be scheduled on cpu 1.
   With some luck, not all of it's context have been thrown out of the
   caches.

This seems nice to me, and I don't see how having several server
threads makes it better. It also get's more complicated if the B
thread happens to be rescheduled onto a different cpu, say cpu 2,
during its processing. In this case, I'd expect A to be woken up and
scheduled on cpu 2, again so that the rpc operation don't cross cpu
borders.

Does it make sense at all to associate sleeping threads to cpu:s?

/Niels