Date: Thu, 10 Jul 2003 03:21:17 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Mike Makonnen <mtm@identd.net> Cc: freebsd-threads@freebsd.org Subject: Re: LinuxThreads replacement Message-ID: <3F0D3E1D.F26FA9E1@mindspring.com> References: <001b01c3463a$0f907a00$0100a8c0@alpha> <20030710001204.GB10504@kokeb.ambesa.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Makonnen wrote: > On Wed, Jul 09, 2003 at 10:11:15PM +0300, Petri Helenius wrote: > > >for example, for on database instance, there are about 80 (lthread) > > >processes hanging around. > > > > I would say with 80 threads you?ll get better performance with libkse > > since you?ll get less contention on the process scheduler. > > It's not as simple as that. In practice a lot of factors about > your system and the type of work you're doing will affect the > performance. On paper, the SA/KSE method is supposed to combine > the best aspects of 1:1 (libthr) and N:1 (libc_r), and should > threoretically be "better" than either one. But, in practice, > complexity and overhead may drown out the performance gains. > Conversely, context switching overhead may not be as great a > penalty for the 1:1 model on modern cpus. The most intersting issue is that the pthread_setconcurrency() controls how many blocking contexts (KSEGs) you have available. If process space is at a premium, you can scale to a much larger number with KSE than you would be able to with Linux threads, since with KSE, the threads are really rather light-weight user space things. You made a statement before that you had 80 threads, and with Linux threads, you were feeling it at 80. I wasn't sure from the context whether you meant 80 was to many for your system or 80 was too few for your application, so I didn't say anything before. But this could definitely be a big factor in your choice of threading library, given your previous statement. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F0D3E1D.F26FA9E1>