Re: critical_enter()/critical_exit() overheads in an SMP system
Matthew Dillon wrote: :pid 214 guid/sec 687816Two TU's running, old critical_*() :pid 214 guid/sec 6876321.454 uS/call :pid 214 guid/sec 687857 :pid 214 guid/sec 687887 :pid 214 guid/sec 667454new critical_*() :pid 214 guid/sec 6675621.496 uS/call -- 41 nS :pid 214 guid/sec 668551 :pid 214 guid/sec 668686 :pid 214 guid/sec 668789 Boy, I'm batting 0 tonight! Those numbers are reversed :-). new_critical is the top number (the faster 1.454 uS/call) and old_critical is the bottom number (1.496 uS/call). I'll have to remember this trick of swapping numbers the next time I have a competitive benchmark that's slower than the competition. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
critical_enter()/critical_exit() overheads in an SMP system
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 [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: critical_enter()/critical_exit() overheads in an SMP system
:pid 214 guid/sec 687816Two TU's running, old critical_*() :pid 214 guid/sec 6876321.454 uS/call :pid 214 guid/sec 687857 :pid 214 guid/sec 687887 :pid 214 guid/sec 667454new critical_*() :pid 214 guid/sec 6675621.496 uS/call -- 41 nS :pid 214 guid/sec 668551 :pid 214 guid/sec 668686 :pid 214 guid/sec 668789 Boy, I'm batting 0 tonight! Those numbers are reversed :-). new_critical is the top number (the faster 1.454 uS/call) and old_critical is the bottom number (1.496 uS/call). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
