>Here's a patch for implementing an interface to system global state. It
>currently carves out a page of the kernel image and keeps xtime in it.
Your gettimeofday has a resolution of 10msec while the stock gettimeofday
has a resolution of 1/CPU_CYCLES_PER_SEC (order of 2pico-sec) on P5 or
more recent x86 machines and of 1/8253_LATCH_DOWNCOUNT_FREQUENCY on 486
and 386 (that is very more accurate than 10msec).
If you don't need precision you could implement a _very_ faster
gettimeofday also with a kernel entry/exit based solution (just return
xtime as opposed to the current code that is entering arch/*/kernel/time.c
and grabbing spinlocks to synchronize with irqs and calculating the
offset from the last timer irq reading the time stamp counter or doing
I/O on the 8253 to read the current value of the LATCH).
Unless you don't accept to have a 10msec max resolution it's not possible
to implement gettimeofday via your mmap or via a special kernel page at
fixed virtual address readable from userspace. BTW, the mmap way has an
higher latency.
A kernel entry/exit based gettimeofday that provides a 10msec resultion
would be fast like getpid, so you can easily get a figure of its potential
speed by replacing gettimeofday(2) with getpid(2) in your bench.
Andrea
-
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/