Messages in this thread | | | Date | Fri, 10 Dec 1999 05:13:09 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: What I suspect : [PATCH] sysdat driver for faster gettimeofday() |
| |
On Thu, 9 Dec 1999, John Wright wrote:
>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/
| |