Date: Sun, 28 Nov 1999 17:39:02 +0000 From: TrouBle <trouble@netquick.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "Richard Seaman, Jr." <dick@tar.com>, Peter Wemm <peter@netplex.com.au>, David Greenman <dg@root.com>, Julian Elischer <julian@whistle.com>, current@FreeBSD.ORG Subject: Re: Which is the truth? (sycalls and traps) Message-ID: <384168B6.D76F8C5@netquick.net> References: <19991128054519.2CB181C6D@overcee.netplex.com.au> <199911281634.IAA44858@apollo.backplane.com> <19991128111949.O1408@tar.com> <199911281728.JAA45072@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ummm Okay are you maybe saying that there is kernel spcae thread support for the current FreeBSD using linux threads ??? if so, is there a way, i can also get a thread supported system using current for some testing also ??? or it is genberic to your installations alone, or is threading actually in 4.0 current using linux threads ?? and does it support pthread_cancel ?? looking forward to a reply Matthew Dillon wrote: > :FYI, some measurements I did with the Linuxthreads "port" (ie. > :native FreeBSD kernel threads using the linux threads code) on a > :266Mhz AMD processor showed the ability to do about 150,000 > :kernel thread context switches/sec. The threads didn't do anything > :other than context switch, so a "real world" context switch might > :be slower, and the rate varies somewhat with the number of threads. > :This was uniprocessor, not SMP. > : > :This suggests that kernel thread context switches, to have a measureable > :impact on performance at even the 1% level, have to be occurring > :at the rate of 1,500/sec or more. With a faster processor, and > :the optimizations you suggest, I'm sure you might well be talking > :10,000 switches/sec to matter. > : > :I don't have any threaded apps that come close to this, but perhaps > :they exist. And, unless you can fix the "user thread" scheduler so > :it doesn't make any syscalls, its hard to see much of an advantage > :for user thread context switches over kernel thread context switches, > :from a performance standpoint. (The current user thread scheduler > :can actually be slower at context switches that kernel threads, > :because of the nubmer of syscalls it makes). > : > :-- > :Richard Seaman, Jr. email: dick@tar.com > :5182 N. Maple Lane phone: 262-367-5450 > :Chenequa WI 53058 fax: 262-367-5852 > > Your numbers mesh with mine very well -- 266MHz AMD @ 150Kswitch/sec, > 450 MHz PIII at around 500K to 1Mswitch/sec (my test was with a simple > entry, context switch, and exit. No floating point in the context > switch). If you include FP state I would expect around 500Kswitch/sec > on a PIII-450. > > Another thing to note is that the overhead is of course for a single > cpu and does not compound when you have additional cpu's. It seems > well worth doing to me. > > Also consider the fact that in a heavily loaded system, scheduling a > thread does not necessarily cause an immediate context switch so we > are really talking about context switches here as being the limiting > factor, not scheduling and descheduling operations, and not asynchronous > message-passing operations. 150Kswitch/sec/cpu goes far beyond what most > systems require. > > -Matt > Matthew Dillon > <dillon@backplane.com> > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?384168B6.D76F8C5>