Re: Better CLONE_SETTLS support for Hammer

[H. Peter Anvin]

Followup to:  <[e-mail]>
By author:    Andi Kleen <[e-mail]>
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

-- 
<[e-mail]> at work, <[e-mail]> 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