[lkml]   [1997]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectStrange CPU usage times with SMP
>>>>> "Chris" == Chris Griffin <> writes:

Chris> I have been running some fairly demainding programs on my
Chris> Dual PPro 200 linux box lately and it is great! I am using
Chris> calles to times() to try to get CPU time usage so I can
Chris> benchmark it against some other platforms I work on. The
Chris> only problem is that when SMP is enabled I get some fairly
Chris> strange times. Sometimes all the time will be system time,
Chris> other times it will all be user time, and as you might have
Chris> guessed, all combinations in-between. If I run this
Chris> program 5 times, I will get 5 different combinations, but
Chris> they will always add up to the same number Even stranger,
Chris> when I run 2 programs at once, and then look at the output
Chris> with top, the USER CPU is 99% and the system CPU is at
Chris> 101%. I assume this has to do with the fact that I have 2
Chris> processors TICKing away. Is this a bug in the kernel, C
Chris> libraries, or just an eventuality that hasn't been taken
Chris> care of yet?

IMHO, this problem, which was discussed in linux-smp, a month ago,
is a cache-affinity scheduling problem. That is, the 2 processes you
run are better run if not changing Cpus all the time, because they
would lose the cache advantage.

What makes me say this is I noticed this on a SPARC 8 Cpus with
Slowlaris 2.4, one year ago. We had, too, enormous system times, and
the same execution of an 8 threads process could range from 1 to
50 times the user time, because of it !!!

Of course, this isn't a trivial problem. Maybe some aging of the
(Cpu x process) could be implemented (a la struct page) to provide
the scheduling mechanism with an accuracy of that Cpu's cache with
that process ...

Any idea/comment/experience on this ???

Herve Regad-Pellagru

SEX: Software EXchange. A technique invented by the blue-green algae
hundreds of millions of years ago to speed up their evolution, which
had been terribly slow up until then.

 \ /
  Last update: 2005-03-22 13:38    [W:0.047 / U:1.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site