Re: Getting Started with Hurd-L4

[Sam Mason]

Marcus Brinkmann wrote:
>Neal H. Walfield wrote:
>> If you do an IPC, do you not donate the rest of your time slice to the
>> receiving process (assuming you don't block).  (Hence the scheduler is
>> not invoked.)

Just out of interest, do you know who came up with this idea?  It's
beautifully simple, and I'm sure I've seen it around before but can't
remember where!

>That seems to be true.  However, like for ThreadSwitch, I'd expect
>this not to be done if the two threads reside on different processors.

Sounds good.  What happens in that case?  The L4 manual is a pretty
big, ominous looking thing!

>L4 will never migrate threads from one CPU to another.  So, both
>threads already have to be on the same CPU for this donation to take
>place.

As far as I know this is almost always what you want - propagating a
thread from one CPU to another is generally quite expensive.  Whether
it's obvious from the amount of code executed or not is a very
different matter though!  Caches and TLBs are going to be thrashed to
pieces during this.

The L4 model may want rethinking with the newer multi-core CPUs that
we're seeing these days though.  That combined with NUMA architecture
is pushing things towards building some sort of hierarchy with the
cost of switching CPUs dependant on how far up the hierarchy you have
to navigate to the other CPU (not sure what the technical term for
this is, it's not a straight distance thing and (as far as I can
remember) only works for tree structures).

>(The spec does not actually say if and how donation takes place at
>IPC.  But the above is what we can conclude from what makes sense and
>what is actually being said elsewhere in the spec.)

Any pointers?

>> Second, assuming the server thread is ready (i.e. in receiving
>> "mode"), it is not running--it is blocked waiting to receive a
>> message.  Hence, it is not on a CPU (it may have a last CPU where it
>> has a small cache footprint but that is different as I understand it).
>
>It seems to me that there is a fixed thread-to-CPU mapping independent
>of thread state, that can only be changed by migrating threads using
>the Schedule system call.

I guess they're expecting something like that scheduler activations
reference I sent earlier to be run on top of them then.  What you've
said so far would make a *lot* of sense if that was the case.

Cheers,
  Sam