> The caches have no difficuties at all with shared data. The cache coherency
> protocol allows the same byte of data to be cached by more than one
> processor at a time.
... but TLB coherency may be a real bitch. Welcome to reality. There is a
very good reason _not_ to have the same MMU context on two processors, at
least unless you've been very accurate with pinning the stuff in core. Any
mapping change in user address space and you have to
* invalidate your own TLB for the region in question
* if there are other CPUs sharing your MMU context - initiate an
inter-processor interrupt.
* on relevant CPUs said interrupt should flush TLB.
Notice that there is no way around it - it's not that any other OS would
be better. The first step is cheap and easy. The rest is going to cost a
lot. Much more than the effect of extra TLB flushes on context switches.
Working around that requires serious efforts on part of program (basically
you either spend a lot of time trying to outsmart the swapper or you wire
all pages - something that system is not going to give you without root
privileges).
Threads made a lot of sense on 286 - _there_ context switch was horribly
expensive. Especially since you had to use segments to squeeze _something_
from this parody on MMU. With the paging MMU of 386 and above sane OS will
have much lighter switches. Popularity of threads is a result of _bad_
mistakes made by several companies - the best known one being the OS/2 1.x
design. It makes very little (if any) sense on normal processors where you
can use COW to avoid data copying in fork() and actively hurts on SMP.
If you need to share a part of data - use mmap() and fork(). It will avoid
the TLB coherency problems (each has its own page tables).
-
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/