Re: SMP performance

Hi again,

Hmm...I have not heard of any specific bug related to SMP scalability or
CPU affinity.  By the way, "CPU affinity" is the ability to "bind" a
process to a specific CPU.  This can be important when it comes the the
CPU cache (known as L2 cache).  The thought is that if you bind a
process to a specifc CPU, then you will waste less CPU cycles on cache
coherency mechanisms.  Cache coherency is the work that the kernel has
to do copying data from the L2 cache of one CPU to the other, before a
process can start executing there.  If you can bind a process to a
specific CPU, you'll avoid the 'pinging', or, the extra work refreshing
the cache between CPUs.  

So, I hope that clears up some of the concepts that you were alluding
to.  However, as I said, I'm not aware of any specific bug in this
area.  Perhaps someone closer to kernel development can provide a reply
to your question.

Also, I did a quick Google search, and I was able to find some postings,
mostly to LKML, where CPU affinity and binding processes to a CPU is
discussed, but it's all in the context of new development on 2.5.x.  I
was not able to find anything in reference to a bug in 2.4.x.

Hope that helps,

-Mark
On Wed, 2002-09-04 at 01:23, Igor Schein wrote:
> 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
-- 
--
Mark J. Bobak
Oracle DBA
[email protected]
"It is not enough to have a good mind.  The main thing is to use it
well."
 						-- Rene Descartes