Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Feb 2002 22:03:41 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Jake Burkholder <jake@locore.ca>, Bruce Evans <bde@zeta.org.au>, Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <alfred@FreeBSD.ORG>, Bosko Milekic <bmilekic@unixdaemons.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, current@FreeBSD.ORG, John Baldwin <jhb@FreeBSD.ORG>
Subject:   critical_enter()/critical_exit() overheads in an SMP system
Message-ID:  <200202250603.g1P63fu46331@apollo.backplane.com>
References:  <20020224131027.I31343-100000@gamplex.bde.org> <200202241912.g1OJCMx95238@apollo.backplane.com> <20020224224927.D35990@locore.ca>  

next in thread | previous in thread | raw e-mail | index | archive | help
    Ok, I've done a more comprehensive test.  TU = getuid() syscall test.
    This is on a 2xCPU SMP box.

    With one process running the syscall is 34 nS faster with the 
    new critical_*().  With two processes running the syscall is 
    41 nS faster with the new critical_*().

    So, not 300nS, but not too shabby.  I expect we'll add another 15-20nS
    of performance later on when the routines are inlined and the sysctl
    instrumentation is removed.  As I said, cli and sti (and the pushfl/popl
    combination) are nasty instructions.  This test is with a 1.1GHz P3
    but I believe it is even worse on a P4.

						-Matt

pid 204 guid/sec 813324		One TU running, old critical_*()
pid 204 guid/sec 813336		1.230 uS/call
pid 204 guid/sec 813513
pid 204 guid/sec 813394
pid 204 guid/sec 813099
pid 204 guid/sec 836959		new critical_*()
pid 204 guid/sec 836779		1.195 us/call		--> 34 nS
pid 204 guid/sec 836939
 
pid 214 guid/sec 687816		Two TU's running, old critical_*()
pid 214 guid/sec 687632		1.454 uS/call
pid 214 guid/sec 687857
pid 214 guid/sec 687887
pid 214 guid/sec 667454		new critical_*()
pid 214 guid/sec 667562		1.496 uS/call		--> 41 nS
pid 214 guid/sec 668551
pid 214 guid/sec 668686
pid 214 guid/sec 668789


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?200202250603.g1P63fu46331>