lkml.org 
[lkml]   [1999]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectClock Watching the Scheduler 2.2.10unip
While trying to determine kernel overhead, I wrote a small pgm
(below) using `rdtsc` to figure out kernel interrupts. I get
some strange results:

1) 500 interrupts take 5 seconds. No surprise there. Except
on SMP (& FreeBSD2.2.8) systems, where they only take
~2.7 seconds. Are these spurrious interrupts? Or SMP?

2) Most interrupts take ~5600 cycles to process on a 530 MHz Cel,
and ~2600 on 200 MHz PPro. This is better than FreeBSD
2.2.8 where they take ~5200 on a PPro 200. But `way longer
than the 700-900 for a hardware int/iret pair.

3) There's considerable scatter in the results, even with caches
turned off. A nice upper tail occurs with other running
processes that shows the length of their timeslices.

4) Most surprising, on the one system I could control caches,
disabling L1 and/or L2 made _NO_ difference. Still 5600
clocks. Is there some cache flushing going on? Why?

Here's clockwatcher:

#include <stdio.h>
#include <asm/msr.h>
#include <linux/config.h>
main () {
unsigned long i, c, t ;
for (i = 0; i < 500; i++ ) {
c = t = 0 ;
rdtscl(t);
do {
c = t ;
rdtscl(t);
} while ((t-c) < 90) ;
printf(" %lu\n",(t-c+32)&-64);
}
}
Best to use as: time ./cw | sort -n | uniq -c | more
-- Robert

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [from the cache]
©2003-2011 Jasper Spaans