Re: [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3)

[Andrea Arcangeli]

On Wed, Mar 03, 2004 at 06:16:52PM -0800, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Andrea Arcangeli wrote:
> 
> > This is just like the kernel patches people proposes when they get
> > vmalloc LDT allocation failure, because they run with the i686 glibc
> > instead of the only possibly supported i586 configuration. It makes no
> > sense to hide a glibc inefficiency
> 
> You apparently still haven't gotten any clue since your whining the last
> time around.  Absolute addresses are a fatal mistake.

the above ldt issue has nothing to do with any address at all, it's all
about deferring the ldt allocation after pthread_create, like
linuxthreads also defer the genreation of the manager thread post the
first pthread_create.

about the vsyscall part (the only thing with a relation with "fixed
addresses"), you can pass the address of vgettimeofday via elf or in any
other way, I'm not forcing you to setup a fixed address, I never spoke
about fixed addresses (infact I specified the elf bit) you can do the
same as the vsysenter, if you're fine with the way vsysenter works you
must be fine using the same way for vgettimeofday too. My only point
(and the only reason I'm against this patch) is that glibc should call
into the vgettimeofday without passing through vsysenter, and in turn
glibc should have _knowledge_ of the existence of vgettimeofday,
otherwise every other regular syscall invoked through vsysenter would
need to pay for it. Now probably we'll never have more than two vsyscall
in x86, so wasting a few nanoseconds for a conditional jump at every
vsysenter may not be measurable but it doesn't look the right design.

And sysenter is at a fixed address in 2.6 x86 too (it doesn't even
change between different kernel compiles).
-
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/