Re: [PATCH v4 0/6] Micro-optimize vclock_gettime
From: Thomas Gleixner
Date: Wed May 18 2011 - 03:30:39 EST
On Tue, 17 May 2011, Andrew Lutomirski wrote:
> On Tue, May 17, 2011 at 6:59 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> > Furthermore any halfways up to date deployemnt is using VDSO for
> > obvious reasons and the archaic stuff which might be affected is not
> > using a recent kernel at all (except for akpm on his retro laptop, but
> > that "performance penalty" is probably the least of his worries).
> Sadly that's not quite true. glibc git right now contains this:
> ENTRY (__gettimeofday)
> /* Align stack. */
> sub $0x8, %rsp
> #ifdef SHARED
> movq __vdso_gettimeofday(%rip), %rax
> PTR_DEMANGLE (%rax)
> movq $VSYSCALL_ADDR_vgettimeofday, %rax
> callq *%rax
I know that, but again: Are statically linked binaries a real issue ?
> And time() and sched_getcpu() call the vsyscall page unconditionally.
Dammit, time() is a real problem. I missed that and thought that it's
gettimeofday() alone for the static case. sched_getcpu() is nothing to
> We should either declare CLOCK_REALTIME_COARSE to be acceptable for
> time() or add a new vDSO call.
> IMO we should put a note in feature-removal-schedule.txt, add vsyscall
> emulation as a config option for 2.6.41 but leave it turned off by
> default, and turn it on by default (or just remove the old code) in
> 2.6.43 or so. That'll give glibc a chance to stop generating *new*
> static binaries that call it.
> I'm not volunteering to dig around the libdl stuff to fix it myself.
> klibc doesn't seem to use vsyscalls or the vDSO. I haven't looked at
> uclibc, and I don't think that Bionic has any released version on
uclibc is safe as well. The VSYSCALL usage is in the futex code, but
is conditional and not used on current kernels. That code is copied
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/