> - - the new library is based on an 1-on-1 model. Earlier design
> documents stated that an M-on-N implementation was necessary to
> support a scalable thread library. This was especially true for
> the IA-32 and x86-64 platforms since the ABI with respect to threads
> forces the use of segment registers and the only way to use those
> registers was with the Local Descriptor Table (LDT) data structure
> of the processor.
>
> The kernel limitations the earlier designs were based on have been
> eliminated as part of this project, opening the road to a 1-on-1
> implementation which has many advantages such as
>
> + less complex implementation;
> + avoidance of two-level scheduling, enabling the kernel to make all
> scheduling decisions;
> + direct interaction between kernel and user-level code (e.g., when
> delivering signals);
> + and more and more.
I'm just starting to look at this... Without digging into it, my
impression is that this is 100% the right way to go. Rob Pike (Mr Plan
9, which while it hasn't had the impact of Linux is actually a fantastic
chunk of work) once said "If you think you need threads, your processes
are too fat". I believe that's another way of stating that a 1-on-1
model is the right approach. He's saying "don't make threads to make
things lighter, that's bullshit, use processes as threads, that will
force the processes to be light and that's a good thing for processes
*and* threads".
My only issue with that approach (I'm a big time advocate of that
approach) is TLB & page table sharing. My understanding (weak as it is)
of Linux is that it does the right thing here so there isn't much of
an issue. In Linux the address space is a first class object so the
id in the TLB is an address space ID, not a process id, which means
a pile of unrelated processes could, in theory, share the same chunk
of address space. That's cool. A lot of processor folks have danced
around that issue for years, I fought with Mash at MIPS about it, he
knew it was something that was needed. But Linux, as far as I can tell,
got it right in a different way that made the issue go away. Which means
1-on-1 threads are the right approach for reasons which have nothing to
do with threads, as well as reasons which have to do with threads.
Kudos to Ulrich & team for getting it right. I'll go dig into it and
see if I've missed the point or not, but this sounds really good.
-- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:29 EST