Re: thread ids, task ids and subsystems

[Espen Skoglund]

[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.

Yes.

> 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.

Perhaps.  Doing a cross cpu IPC will require, compared to a cpu local
IPC, a larger amount of kernel intervention on both cpus; inclding
access to both code and data.  This will cause larger parts of the
client and servers cache working set to be evicted.  You calculation
must therefore take the working set sizes of both client and server
into account (i.e., the working set required to service a single
request).  (And you should of course take the actual overhead of the
cross cpu IPC in addition too.)

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

Indeed.

        eSk