Re: thread ids, task ids and subsystems

[Marcus Brinkmann]

On Thu, Apr 10, 2003 at 04:39:20PM +0200, Niels Möller wrote:
> > > (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.

Well, I look through the L4 X.2 specs back and forth, but as far as I can
tell threads are not migrated from one CPU to another automagically.  A
thread runs on a given CPU, and if you want it to run on a different CPU,
its scheduler thread needs to migrate it with the schedule IPC (and this
seems to be a "slow" operation in the sense that threads should best be
created on the CPU they are intended to run on).

Also, the ThreadSwitch IPC has a destination thread parameter to which you
can donate your remaining timeslice, and if the destination thread runs on
a different CPU, it is ignored.  Might be a further indication that L4
doesn't bother to move threads between CPUs.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/