Messages in this thread | | | Subject | Re: Per-Processor Data Page | Date | Thu, 9 Dec 1999 02:46:15 +0000 (GMT) | From | Alan Cox <> |
| |
> 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 wants.
> 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.
Alan
- 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/
| |