lkml.org 
[lkml]   [1999]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.045 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site