On Mon, Apr 24, 2000 at 04:44:05PM -0500, Richard Seaman, Jr. wrote:
> On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote:
> > FreeBSD's threads should perform adequately given the design of your program
> > and the hardware you listed. Actually trying it on the various operating
> > systems would be a good exercise, but I have found that FreeBSD's threads
> > perform at least as well as Solaris's for such an application.
>
> Interesting. I would have thought Solaris would be much superior.
>
> > LinuxThreads will definitely bog down with so many threads because the
> > kernel scheduler has to deal with so many clone()d processes.
>
> Somewhat. But its nothing compared to the slowdown in the libc_r scheduler,
> in my experience. Each context switch (or each time the libc_r scheduler
> examines its state to consider a context switch), it executes a poll call
> to examine the state of *each* file descriptor that is considered "blocked"
> (of course its not really blocked in the kernel -- libc_r converts all
> i/o calls to non-blocking and polls their status to determined when i/o
> can be done). If you have hundreds/thousands of threads and each has an
> open file descriptor that has to be polled, linuxthreads is much faster,
> at least for the tests I've run. However, linuxthreads will consume a
> lot more kernel resources, so this only holds if you can tolerate the load
> on your resources.
Interesting. Unfortunately, when I was developing the server I referred
to, I was never able to get past about 100 connections on FreeBSD without
crashing the kernel, because of the static buffer limits in the kernel
(yes, I manually specified very large mbuf limits). As a result, I never
experienced the scaling problems you mention. =)
Linux runs into problems at less than 4000 threads because of a limit on
the total number of processes, even if the thread stack size is decreased.
I have run threaded tests on Solaris with over 30,000 connections without
problems, other than kernel deadlock due to resource starvation when
stuffing too many kernel-side socket buffers with data.
> > FreeBSD's libc_r does not use clone() or anything similar. Instead, it is
> > a userland call conversion library that multiplexes threads in a single
> > process. This style of threads library should perform well for the type of
> > application you are dealing with.
>
> Perhaps. The proposed "new" threads model that I understand you are working
> on should be *much* superior in this kind of application to either libc_r or
> linuxthreads, I would think.
I hope so, because it's going to be a bit of work. =)
Jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
