[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: thread ids, task ids and subsystems
From: |
Marcus Brinkmann |
Subject: |
Re: thread ids, task ids and subsystems |
Date: |
Fri, 11 Apr 2003 19:51:14 +0200 |
User-agent: |
Mutt/1.5.3i |
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/
- Re: thread ids, task ids and subsystems, (continued)
- Re: thread ids, task ids and subsystems, Marcus Brinkmann, 2003/04/07
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/07
- Re: thread ids, task ids and subsystems, Marcus Brinkmann, 2003/04/07
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/07
- Re: thread ids, task ids and subsystems, Marcus Brinkmann, 2003/04/07
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/07
- Re: thread ids, task ids and subsystems, Marcus Brinkmann, 2003/04/08
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/08
- Re: thread ids, task ids and subsystems, Marcus Brinkmann, 2003/04/10
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/10
- Re: thread ids, task ids and subsystems,
Marcus Brinkmann <=
- Re: thread ids, task ids and subsystems, Espen Skoglund, 2003/04/11
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/11
- Re: thread ids, task ids and subsystems, Marcus Brinkmann, 2003/04/11
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/11
- Re: thread ids, task ids and subsystems, Espen Skoglund, 2003/04/11
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/11
- Re: thread ids, task ids and subsystems, Espen Skoglund, 2003/04/11
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/10
- Re: thread ids, task ids and subsystems, Marcus Brinkmann, 2003/04/10
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/10