[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.097 / U:0.824 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site