Re: thread ids, task ids and subsystems

[Niels Möller]

Espen Skoglund <address@hidden> writes:

> Eh... why would it make sense to target a server thread on another
> cpu.  If there is a server thread on the current cpu it definitely
> pays of to send the rpc to this one (no working set migration, not
> inter-cpu communication, direct switching to the server thread).

Your argument about working sets seems to imply just that. You said
it's faster to do the rpc cross cpu, than to migrate the server's
working state to cpu 1.

Consider a system with only two active tasks (or two threads), the
client and server. If the client runs on cpu 1 and the server on cpu
2, each thread can use all of its cpu's cache. If the server also have
a sleeping thread on cpu 1, sending it rpc:s will cause more
competition for the cache on cpu 1, while leaving cpu 2 idle.

I guess the optimal behaviour will also be different for a heavily
loaded system and a mostly idle one.

> As for the reply port, it really depends on how you implement it.

My point here was just the observation that the ways of identifying a
server port and a reply port will be different. But perhaps that's no
big deal.

/Niels