Messages in this thread | | | Date | Thu, 4 Mar 2004 03:47:39 +0100 | From | Andrea Arcangeli <> | Subject | Re: [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3) |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |