Re: Better CLONE_SETTLS support for Hammer

Andi Kleen (ak@suse.de)
Wed, 5 Mar 2003 22:19:49 +0100


On Wed, Mar 05, 2003 at 11:25:26AM -0800, Ulrich Drepper 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

loadsegment and preparation has to be done anyways for compatibility
(we tried to do that lazy too, but failed)

The 64bit base switch is additional cost.

>
> > 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.

I would definitely prefer double thread-create/delete costs over even
slightly higher context switch costs. Compared to a context switch a
thread creation or deletion is a once-in-a-millenium event.

-Andi
-
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/