Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 28 Nov 1999 14:32:50 -0800 (PST)
From:      Julian Elischer <julian@whistle.com>
To:        "Richard Seaman, Jr." <dick@tar.com>
Cc:        arch@freebsd.org
Subject:   syscall overhead.
Message-ID:  <Pine.BSF.4.10.9911281428460.544-100000@current1.whistle.com>
In-Reply-To: <19991128111949.O1408@tar.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On Sun, 28 Nov 1999, Richard Seaman, Jr. 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).
> 

yes but have we catalogued those calls?
I am guessing that we can probably get rid of a lot of them by appropriate 
kernel support.

For example threads blocking and unblocking signals for various reasons..
I'm certain we could do the same lazy blocking that the kernel
presently does So that blocking a signal would be simply a case of 
setting a bit.







To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9911281428460.544-100000>