[lkml]   [1999]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Per-Processor Data Page
    >    4) For pthreads, it is required to have a notion of thread private storage.

    Its worth remembering that pthreads is not a good API for efficient performance.
    Several people are not using pthreads, others would drop it except for the
    fact you are stuck with the pthreads locks buring in glibc and seperating
    the two is hard.

    You also rarely want thread private storage. Most applications require
    task (in the job to be handled sense) specific storage. My media-server hack
    for example has file handle specific storage because thats what it really

    > a thread to access a pointer to its private data. (User level threading
    > schemes, and M-N schemes can also use this mechanism, albeit with
    > a system call to establish a new value for the private data pointer)

    Usermode threading can do the same tricks that the kernel does with %esp
    masking. On real processors (ie non x86) registers are cheap enough you can
    use one for thread storage. The %esp trick overhead generally outweighs
    the TLB flush overheads and nowdays is cheaper than segment overrides

    Having access the the pid at a fixed address is as good as the %esp trick if
    not better. Unfortunately it means you now have to rewrite it each context
    switch or flush the TLB. Both of these suck. This is one obvious reason for
    not putting the pid in such a page. On platforms like the ARM and PA-RISC
    this is a big big issue, on X86 it sucks slightly.

    > 6) Kernel stacks must be fixed in size and aligned on 2-page boundaries.

    Depends on the platform. Most non x86 cpus have registers and we keep
    'current' in a register. It makes for faster smaller code as well. To go
    over a 2 page boundary requires the stack is virtual not physical. At that
    point you can have holes in the stack to do alignment, you can do all sorts
    of tricks.

    > A solution to the above set of problems is to provide a fixed virtual mapping
    > to a pair of physical pages which are associated with each processor, and to
    > ensure that this mapping is used by a thread of execution when executing on
    > said processor.

    TLB flush per context switch. Thats a big lose. The magic page has to be
    constant, and globally mapped.

    > Pros:
    > 1) Decoupling the task_struct from the kernel stack makes many
    > enhancements of the kernel stack architecture possible including
    > but not limited to:
    > 1) Larger kernel stacks

    We can do that anyway. Larger stacks are bad. 4000 processes at 8K a process
    is a lot of memory, more would suck.

    > 2) Variable sized kernel stacks
    > 3) Automatically growing kernel stacks.

    No. Your allocation might fail in an irq, or you might need to do a stack
    grow during a block I/O page out to allocate memory. Deadlock death.

    > 3) Thread-private data can be implemented efficiently.

    It can already. The %esp trick is fast.

    > 4) Some system calls, especially those that return static data,
    > can be implemented very efficiently - not requiring a kernel
    > boundary crossing.

    At a huge cost. Static system calls can be handled by simply caching the
    values in the C library. Its silly to force tlb flushes for this.


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

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