l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?


From: Espen Skoglund
Subject: Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?
Date: Tue, 24 Jul 2001 16:41:20 +0200 (CEST)

[Farid Hajji]
> Why is it such a problem for L4 to support a larger number of
> threads?
>  1. thread-id has too few bits?
>  2. run-queues get too large?
>  3. other reasons?

> Is 1. really a limitation? I don't know about x86, but with 64-bit
> CPUs or with CPUs with large register sets, the thread-id field
> could easily be much bigger.

> 2. can be a problem, because the total size of the kernel would grow,
> therefore filling the caches. Traversing the queues is not the
> issue, since insert() and pop()- operations are O(1).

> Are there plans to support a larger number of threads or a N:M
> thread model in future L4 versions?

L4 Version X.0 has 32 bit thread IDs.  Since thread IDs contain both a
task number, a chief identifier, and a version number, this leaves
only 6 bits for in-task thread IDs (64 threads, X.0 was always meant
to be an eXperimental version to try out new ideas, nothing to put
into production use).  In L4 Version 2, thread IDs are 64 bits, but
in-task thread IDs are still only 7 bits (128 threads).  Reason 1 is
therefore the only reason why there is a limitation to the number of
in-task threads in the current L4 versions.

We've found that this way to specify thread IDs are far too
restrictive---tasks usually either contain just a few threads or they
contain a large number of threads.  L4 Version X.1 (never implemented)
therefore went about alleviating the problem by having a variable
sized thread ID/task ID.

Future versions of the L4 API (X.2, Version 4) will not have these
restrictions.  A Version 4 thread ID will not contain neither a task
identifier nor a chief identifier (the chiefs & clans model has been
abolished).  The idea is that there should be no practical restriction
to how many threads a given task (address space) can contain.

Conclusion: you could assume that there is no restriction to the
number of threads a given address space may contain.  How this is
achieved inside the kernel is not your problem.  It is something that
we (the kernel developers) should take care of.  Of course, the
current X.0 kernels are not really useful with the Hurd if you make
this assumption.  You could, however, get a long way with it, and when
Hurd/L4 has gotten somewhat closer to a useful state we will probably
have a fully fledged Version 4 kernel to put beneath the Hurd.

Conclusion 2: do not tie your L4/Hurd design too tight together with
current L4 versions.  I.e., do not make the same mistake as when the
Hurd was implemented on top of Mach.  Of course, everybody is pretty
much aware of this by now, but I though it wouldn't hurt to mention it
one more time.

        eSk



reply via email to

[Prev in Thread] Current Thread [Next in Thread]