On Thu, 24 Feb 2000, Rainer Keller wrote:
> Kernel 2.3.47 real: 21m32.763s 491815 Bytes
> user: 19m35.340s
> sys: 1m13.340s
>
> Kernel 2.3.47-OPT real: 20m15.021s 491921 Bytes
> user: 18m20.580s
> sys: 1m 4.930s
these numbers are _highly_ suspect. entry.S micro-optimizations _never_
show up in a measurable way in any macro-benchmark. Even switching to fast
system calls (which shaves off 130 cycles) only showed up in a few
microbenchmarks.
A full kernel compilation like the above uses less than 100k system calls.
Even optimistically assuming 100 thousand system calls, the above numbers
mean that your change saved 11185 cycles per system call. (on a 133 MHz
Pentium) Not to mention that the above code also shows better user-space
numbers, showing another 25000 cycles improvement on the user-space
side...
nevertheless it's possible to measure accurately how much improvement your
code brings, i've attached pid.c which is a very simple null-syscall
latency tester, i used it for doing similar experiments :-) Run it several
times to hit the correct cache alignment scenario which produces the best
latency number. Here i get:
moon:~/asm> ./pid
-> 1964 cycles
-> 494 cycles
-> 329 cycles
-> 290 cycles
-> 280 cycles
-> 279 cycles
-- mingo
-
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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:11 EST