Re: benchmarking squid on solaris/x86

From: Lincoln Dale <ltd@dont-contact.us>
Date: Thu, 21 Mar 2002 13:11:09 -0800

At 05:55 AM 21/03/2002 -0700, Adrian Chadd wrote:
>A freebsd/solaris developer friend of mine did it to prove to
>a bunch of freebsd and solaris bigots that solaris _can_ be
>as fast as FreeBSD/Linux on a single CPU.
>
>The FreeBSD/Linux guys, obviously, don't run SMP kernels on
>non-SMP machines, because there's a noticeable speed difference.
>:)

i still don't agree with you.

Linux 2.5 now has "preemption" as an option. its meant for uniprocessor
systems.

i don't agree that "SMP on UP is effectively spending lots of time locking"
as the big performance hit on SMP isn't from doing atomic operations on
bits but rather than IPI (inter process interrupts) to ensure that the
memory-write has propogated to other processors in the system.

when you have a single processor, you have no need to do:
  - atomic updates
  - use read/write memory-barriers
  - send out processor IPIs
  - wait many many cycles to ensure that the IPIs have been propogated to
all cores

>For fun - The FreeBSD and Linux people have been working on making
>a single SMP-aware kernel image for some time now. The problem
>is that SMP kernels on single-CPUs waste a lot of time locking
>data which doesn't need to be locked.

not really; on uniprocessor, a lock can be as simple as:

         int *spinlock;
         ...
         *spinlock = 1;

(or, if paranoid about gcc's optimizations, something like
         volatile int spinlock;
         ...
         spinlock = 1;
         ...)

>When you have kernel modules
>they can be compiled with or without the SMP mutexes - which
>are inline (for speed) - with SMP modules on a non-SMP box they
>run slower, and non-SMP modules on an SMP box .. yeah. Bad
>things happen.

i still don't agree with this. the locking primatives don't have to be
inline functions.

>When I was doing FreeBSD kernel hacking, the other kernel guys
>where - at boot/module load time/ - going to take a list of
>all the inline mutexes and NOP them out if the machine has a single
>CPU. That way, binary-only kernel distributions can work regardless
>of what the machine is, so you don't need to recompile the kernel
>unless you want to change the code (rather than some parameters/options).
>
>Its all rather cute, actually. :-)

in linux's case, one can be smart about organising the segments for the
linker. SMP locks can be put in ".text.lock" segment which can be dropped
at module load-time by the module-loader for reducing memory waste.

cheers,

lincoln.
NB. no discussion on kqueued/kevent stuff ...?
Received on Thu Mar 21 2002 - 14:20:59 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:52 MST