[lkml]   [2003]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Better CLONE_SETTLS support for Hammer
    On Wed, Mar 05, 2003 at 10:55:50AM -0800, Ulrich Drepper wrote:
    > Please consider using this patch which changes the way CLONE_SETTLS is
    > handled on Hammer completely. The old approach was to slavishly follow
    > what x86 does with the desastrous result that TCBs (and therefore
    > stacks) could only be allocated in the low 4GB. This would have been a
    > really bad limitation going forward.

    Why stacks? is there a technical reason %fs has to point in the same
    area as the stack?

    If you just want to save one mmap/allocation: I think the context switch
    overhead will be more expensive than the allocation.

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

    I had hoped that user land would prefer fast context switches and
    just stuff the index tables for the thread local data into the
    first 2GB (using MAP_32BIT). Yes limiting the thread stacks to 4GB
    would be bad I agree, but is it that big a problem to split the
    index table for thread local data and the stack?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:33    [W:0.024 / U:0.776 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site