Messages in this thread | | | Date | Sun, 12 Jan 1997 23:14:44 +0100 | From | "Herve R.-P." <> | Subject | Strange CPU usage times with SMP |
| |
>>>>> "Chris" == Chris Griffin <boozer@vanadium.rollins.edu> 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.
| |