Date: Sun, 28 Nov 1999 09:28:48 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Richard Seaman, Jr." <dick@tar.com> Cc: 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: <199911281728.JAA45072@apollo.backplane.com> References: <19991128054519.2CB181C6D@overcee.netplex.com.au> <199911281634.IAA44858@apollo.backplane.com> <19991128111949.O1408@tar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911281728.JAA45072>