Andi Kleen wrote:
> 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.
And the loadsegment() call with all the preparations if faster? And
faster in future revisions of the processor? Since I cannot get any
recent kernel to run you'll have to do the timing. I wouldn't expect
the difference to be significant.
> but is it that big a problem to split the
> index table for thread local data and the stack?
Yes, it it. It would basically double thread create-destroy costs.
double the internal administrative overhead (and time and memory), would
add more dcache pressure, and so on. It is simply stupid. We don't
have to do it for any other architecture, so don't force such hacks on
us for an architecture whose lifespan just starts.
- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+Zk8m2ijCOnn/RHQRAiUWAJ4o3akYg11tw4PGoIrqln3r/9v4kQCgm+MD
kcrsGMVa0Z++yccEkxolxX8=
=gHz/
-----END PGP SIGNATURE-----
-
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/