lkml.org 
[lkml]   [1999]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Thread-private mappings and graphics (was Re: Per-Processor Data
       Date:   Mon, 13 Dec 1999 23:54:15 -0800
    From: Jon Leech <ljp@oddhack.engr.sgi.com>

    This doesn't address the problem. First, the threads need to
    refer to *different* graphics contexts. Second, the API requires
    that these contexts be identified by some thread-specific mechanism
    available to the graphics library, not by explicit stack pointers
    in the application - whether that mechanism is private mappings or
    tarot cards matters not, so long as it's extremely fast.

    So fork()'d processes store the graphics library shared state in
    a shared/writable mapping area.

    What you proposed is: threads + thread local mappings
    Linus is suggesting instead: processes + shared mappings

    The latter provides what you'd like to do without any of the
    overhead or complexity assosicated with the former. And I think
    that alone will make up for whatever performance advantages are
    obtained by the former.

    As someone who intern'd at SGI for a few months and also saw how the
    aforementioned IRIX mechanism works, I can definitely say this is
    something we never want in Linux. TLB miss trap handler changing
    based upon if the thread has thread-local mappings, all the special
    cases in vfault/pfault to find the correct page tables to lookup, no
    thanks.

    Later,
    David S. Miller
    davem@redhat.com

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.021 / U:0.100 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site