Re: SMP performance

On Wed, Sep 04, 2002 at 12:54:01AM -0400, Mark J. Bobak wrote:
> Hi Igor,
> 
> Um, hmmm..where to begin?
> 
> First, SMP performance, good or bad, is almost certainly a function of
> the kernel and is not a Gentoo specific problem.  

I guess I didn't put the correct emphasis in my statement.  I know
it's a general kernel issue.  I think it's called CPU affinity, though I
have no clue what it means.  This performance issue exists in both
Redhat and Gentoo, but I figured latter is more likely to incorporate
the relevant patch.

> 
> Second, I'm not aware of any SMP performance problems in recent 2.4.x
> kernels.  
> 
> Particularly where we are speaking of 2 CPUs boxes.  2 CPU boxes offer
> the most scalable SMP performance, in terms of being closest to the
> theoretical limit.  Although I've not tried it, 4 way is reportedly
> still quite scalable on 2.4 kernels, but beyond that, you reach the
> point of diminishing returns.  As the 2.5 devlopment continues and the
> BKL (Big Kernel Lock) is further eliminated, Linux will scale better and
> better on larger SMP boxes, 8 CPUs and beyond.
> 
> If you can cite examples of SMP scaling problems, I (and probably others
> on the list) would be interested in seeing them.
> 
> One last thought comes to mind:  If the tasks you speak of are I/O
> bound, and (for example) do lots of sequential disk reads, but each task
> reads different parts of the disk, then any SMP gains you may have
> benefitted from by running tasks concurrently will surely be wiped out
> due to latency of disk head seek times.  In this case, running the
> processes sequentially would almost certainly be the winner.  But, that
> doesn't say anything about SMP scalability of the Linux kernel.  It
> tells you something about the seek and access times of your hard drive. 

That would be too easy, wouldn't it.  The applications I tried are
purely CPU-intensive, no I/O whatsoever, no heavy memory use.  They
run nicely in cache.  I'll try to explain to the best of my ability
what I think is happening.  The processes are not able to reuse
whatever's cached in L2.  It might have to do with a process not being
locked to a CPU, though I am just speculating here.

Thanks

Igor