Messages in this thread | | | From | "H. Peter Anvin" <> | Subject | Re: Better CLONE_SETTLS support for Hammer | Date | 5 Mar 2003 21:33:44 -0800 |
| |
Followup to: <20030305190622.GA5400@wotan.suse.de> By author: Andi Kleen <ak@suse.de> In newsgroup: linux.dev.kernel > > > > But as it turns out the kernel already has support for handling %fs in a > > different way, to support prctl(ARCH_SET_FS). So let's just use the > > same mechanism. clone() will simply take an 64-bit address and use it > > as if prctl() was called. > > The problem is that the context switch is much more expensive with > that (wrmsr is quite expensive compared to the memcpy or index > reload). The kernel optimizes it away when not needed, but with > glibc using them for everything all processes will switch slower. >
This is almost certainly the biggest brainfuck in the x86-64 architecture. It should have been supported to set the segment registers via "movq rm64,%fs|gs" (i.e. REX64 MOV sr,r/m64). Barring that, it would have been better if *all* setting of the segment registers from userspace had been completely outlawed, so the kernel at least could have tracked the usage. The combination is in so many ways worse than ever.
IMNSHO we should assume in the ABI that this will be fixed at some point, and therefore we shouldn't work too hard to create kluges that are based on warts in the first x86-64 generation (K8) only, that later can't be fixed.
There is plenty of reason to believe the x86-64 architecture will be around for a long time to come. It is more important to create sane ABIs than it is for those ABIs to be microoptimized to the first generation of x86-64 processors.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64 - 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/
| |