Re: Tread/Task IDs

[Joshua LeVasseur]

Some reasons for a 32-bit thread ID on a 32-bit architecture (as 
opposed to a 64-bit TID):

- a 32-bit TID uses only a single register in the register file.  The 
fastest IPC is that which completely transfers its message within the 
register file, without spilling to memory.  If you use a 64-bit ID, you 
would consume another physical register, and it would be seen as a real 
performance hit on some architectures (such as ia32) which would have 
to transfer more messages in memory.

- the semantics of the TID space has a direct effect on the speed at 
which the kernel can map a TID to its kernel thread-control-block.  If 
you look at the implementation, you'll see that a TID is efficiently 
converted to a KTCB with a mask, shift and add.  We don't use memory 
references, and thus no table lookup to convert a TID to a TCB 
location.  On ia32, which flushes its TLB with every address space 
switch, an extra memory reference per IPC would penalize performance 
even more.   You can fit 131,072 KTCBs in a 256 MB address range (for a 
1024-byte KTCB).  A 32-bit TID is large enough to encode the usable TID 
space; a 64-bit TID would be superfluous.

- to support fast local IPC, a local TID is the pointer to its 
respective UTCB (and is distinguishable from a global TID).  On a 
32-bit arch, a pointer is obviously 32-bits.  A 64-bit TID would again 
be superfluous.

Josh



On Tuesday, May 6, 2003, at 10:37 PM, address@hidden wrote:

> What was the rationelle for not using a full 64-bit thread/task ID on
> both 32- and 64-bit systems?  How large would the performance hit be?
> Surely at least a full macine register for the task ID was considered
> for the X.2 API.  Why was it rejected?  I assume it has to do with not
> wanting multi-level thread ID tables for performence reasons.  How
> large would the performence hit be?
>
> I admit I have only dabbled in kernel space and I usually do 
> cryptographic
> stuff in userspace with 128-bit or 256-bit IDs.  Maybe I'm just jaded 
> from
> huge IDs.  However, it would seem to me that there would be many fewer 
> hacks
> if IDs were at least 32-bits, if not 64-bits.
>
> I'm sure the X.2 API was very well thought out, I'm just a little 
> surprised
> at the kludges HURD is forced to consider due to the L4 API.  I'd like 
> to
> see what I'm missing.
>
>
> -Karl -- ignorant userspace coder
>
>
> _______________________________________________
> L4-hurd mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/l4-hurd