[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-smp
Subject:    Re: Performance...
From:       Constantine Gavrilov <const-g () Orbotech ! COM>
Date:       1999-09-30 16:14:32
[Download RAW message or body]

Ted Parnefors wrote:
> 
> I just recently got myself an ASUS P2B-D board and equipped it with two
> P-III 450 processors, and everything seems to be running just smoothly and
> fine with a 2.2.12-SMP kernel... BUT... There is something that is bugging
> me, and it might have a very logical explaination to everybody except me
> since I'm not an expert on how Linux handles scheduling between
> processors. Anyway, what got my attention is that when running some number
> crunching single threaded processes, I was expecting to see that one
> processor was to be fully occupied, but that's not the fact, instead one
> has 42% load and the other 63%, or maybe sometimes the load is dispersed
> 25/80 between the processors, or similarly. But the funny thing is that it
> close to always seems to be a total load of 105 %... How come? If the job
> gets split up between the two processor how come they aren't fully used
> then?? And why is the total 105 % and not 100 % ? Just curious... :)
> Anyone happen to have an explaination?
> 
> Cheers!
>   -Ted Parnefors
> 

Processes running in Linux SMP environment have CPU affinity. That means that
they are likely (but not guaranteed) to run on one CPU. The migration to another
CPU (context switching) may happen, when the kernel "decides" that it is better
to do so. Typical reason of migration is servicing of interrupts by CPUs. Linux
2.2.X kernels load balance the interrupts between CPUs (look at
/proc/interrupts) and are multi-threaded (at least in part). This was done in
order to insure scalability (if interrupts can be served by both processors and
there is no kernel global lock that means when some kernel thread is entered,
another kernel thread or a user process can run in parallel with it).

Thus, if a process runs on CPU1 and CPU1 services an interrupt (and thus enters
a kernel thread), the process may migrate to the second CPU. The frequency of
migration will very much depend on the processes running and on how and which
hardware devices are used. To some extent, it will also depend on the
motherboard implementation. Frequent process migration (several times a second)
could be a problem, because each context switching has a penalty of copying the
data from the cache of one CPU to the cache of another. Frequent context
switching means that either your application or another running process require
much system time (system time is a time spent by a process in kernel). The
normal situation is when a process switches each 10-30 seconds; there is no
measurable penalty for that. You cannot bind a specific process to a specific
CPU without applying special patches to the kernel.


Regarding the CPU utilization, Linux is a multitasking system. You have your
application running, some daemons running, and a process monitor utility running
(like top -- else how would you know the statistics?). If your single threaded
application consumes 100% CPU, the extra 5% accounts for daemons + top utility.
Also, each process monitor utility (like top) averages the CPU load over each x
seconds. So when you see 60% and 40%, it means that during last x seconds, CPU1
was "working" 60% of the time and CPU2 was "working" 40% of the time. For a
system which has only one "major" process running, the sum of the numbers should
be around 100% and the ratio of the numbers shows what part each CPU has played
in servicing the job. Of course, depending on how busy your system is, both of
the numbers can be in the range of 0-100% (total maximum load for a dual system
is 200% -- this is at least how most of the utilities report the load on a SMP
system).

Even a single threaded application can take more than 100% of CPU time on a SMP
system (at least in a theory). The parts of a single threaded application which
contribute to the USER time can never load the system more than 100%. The parts
of the application which contribute to the SYSTEM time can, since kernel itself
is multithreaded. So, depending on what application is doing, it could take more
than 100% CPU, system and user time accounted for.

I hope that helps.

-- 
----------------------------------------
Constantine Gavrilov
Unix System Administrator and Programmer
Orbotech
Yavne 81102, Israel
Phone: (972-8)-942-3064
Fax:   (972-8)-942-3800
----------------------------------------
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to majordomo@vger.rutgers.edu

[prev in list] [next in list] [prev in thread] [next in thread]