On Fri, 4 Feb 2000, Thomas Charron wrote:
>> You can't make that scheduling overhead go away simply by moving it out
>> of the kernel.
>
> Yes, but you have different issues.
You're right. By putting threading in the kernel, you get MP scalability
and a more selective interface to resource segmentation, neither of which are
easily possible in userland.
> An example usage of different thread implementations would be the pth
> library. This is a userland threading library, that does not use kernel
> threads themselves. Using it, I can easily handle 30,000 threads of
> execution, without a hitch. Now, 30,000 kernel threads, well.. Let's
> just say ps -ax would be rather lengthy, as soon as the OS got around to
> actually running it.
The "ps" program on Linux has a known performance problem when a lot of
processes running (it has to walk the /proc tree and parse all the text
"files" in there). Furthermore, it's display of threads is confusing and
nonstandard. I have no idea if there are any plans to fix any of these
problems, but procps is a bad indicator of overall system performance.
Now, I don't know what kind of performance Linux has with 30,000 processes
running at once. I've never met a situation where Linux was having that kind
of demand put on it. But, if you do really have 30,000 concurrent threads
running (and not 1 thread running with 29,999 blocked)... I imagine you're
either going to have a pretty hefty machine or one hell of a performance hit,
regardless of the thread implementation.
> Perhaps it's the scheduler, I, not that sure, but the fact of the matter
> is, kernel threads require a whole lot more overhead then they need to.
On what do you base that assertion? From everything I've read, kernel
threads have significantly *lower* overhead because of the way Linux
implements them. The URL I posted talks about some of that. Now, while I can
believe that there may be other opinions, I do require a bit more then "Thomas
Charron says so" as evidence. :-)
--
Ben Scott
[EMAIL PROTECTED]
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
