The following patch implements a shared memory interface to allow
implementing gettimeofday (and other clock measurement) using the TSC
counter on i386. On a 1.6G Xeon this reduces gettimeofday from 1.2 us
per call to .17 us per call.
The interface is through a /proc/tscinfo that is mmap'd by the library.
If the kernel doesn't have working TSC and/or has NUMA TSC problems then
the /proc file will not exist and the library should fall back to a
syscall.
Attachments:
patch for 2.4.20-pre5
sample library routine
That seems awfully heavy handed for TSC, as well as reducing your
accuracy massively.
Followup to: <1031267553.10830.71.camel@dell_ss3.pdx.osdl.net>
By author: Stephen Hemminger <[email protected]>
In newsgroup: linux.dev.kernel
>
> The following patch implements a shared memory interface to allow
> implementing gettimeofday (and other clock measurement) using the TSC
> counter on i386. On a 1.6G Xeon this reduces gettimeofday from 1.2 us
> per call to .17 us per call.
>
This sounds like a vsyscall. Since we have discussed vsyscalls on and
off without getting anywhere, I'd like to know how your implementation
does it -- the #1 proposal I think was to map in a page at 0xfffff000
and have the vsyscall code there.
Note that the vsyscall needs to bounce to a regular syscall if TSC
time/gettimeofday aren't available.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
> This sounds like a vsyscall. Since we have discussed vsyscalls on and
> off without getting anywhere, I'd like to know how your implementation
> does it -- the #1 proposal I think was to map in a page at 0xfffff000
> and have the vsyscall code there.
Id like to do a similar thing on ppc32 and ppc64. It would be good to
make some of this generic before everyone implements it their own way.
Of course the lower level stuff will be arch specific, but some of it
could be the same (like how do we handle ptracing into the area? Do
we COW or do we deny it and fix gdb to unsderstand vsyscalls).
Anton
Hi!
> > This sounds like a vsyscall. Since we have discussed vsyscalls on and
> > off without getting anywhere, I'd like to know how your implementation
> > does it -- the #1 proposal I think was to map in a page at 0xfffff000
> > and have the vsyscall code there.
>
> Id like to do a similar thing on ppc32 and ppc64. It would be good to
> make some of this generic before everyone implements it their own way.
>
> Of course the lower level stuff will be arch specific, but some of it
> could be the same (like how do we handle ptracing into the area? Do
> we COW or do we deny it and fix gdb to unsderstand vsyscalls).
It is already implemented on x86-64.
AFAIR putting breakpoints into vsyscall area is not permitted.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.