Haris Volos wrote:
Bart Smaalders wrote:
Haris wrote:
Today Solaris uses per-process TSBs, so walking a TSB
to clear
out entries for a stolen context is never necessary.
In addition,
e now use grouped assignment of mmu contexts; this
means that
if a context needs to be stolen we only need to
cross-call
other cpus in its mmu context domain instead of every
cpu in the box.
Take a look here for details:
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/
usr/src/uts/sfmmu/vm/hat_sfmmu.h#289
What about the TLB? TLB still has entries from multiple contexts, right?
Yes.
I was looking at the code you pointed me and I have a question about
the mmu context domain. What is meant by MMU context domain? The
subset of CPUs that have entries for a context space?
The idea is that a set of cpus can have the same idea of
addresss space -> mmu context id mappings. Thus, when stealing
a mmu context, only the set of CPUs in the mmu context domain need
to receive cross-calls.
Note that on threaded processors, virtual cpus on the
same core (threads) share the same TLB:
From
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sfmmu/vm/hat_sfmmu.c#1370:
/*
* plat_cpuid_to_mmu_ctx_info() is a platform interface that returns MMU
* context domain information for a given CPU. If a platform does not
* specify that interface, then the function below is used instead to
return
* default information. The defaults are as follows:
*
* - For sun4u systems there's one MMU context domain per CPU.
* This default is used by all sun4u systems except OPL. OPL systems
* provide platform specific interface to map CPU ids to MMU ids
* because on OPL more than 1 CPU shares a single MMU.
* Note that on sun4v, there is one global context domain for
* the entire system. This is to avoid running into potential
problem
* with ldom physical cpu substitution feature.
* - The number of MMU context IDs supported on any CPU in the
* system is 8K.
*/
- Bart
So, when creating a new process, is it possible that the address space
get mapped to different context IDs for different MMUs?
yes. This significantly improves performance with a large number
of processes and multiple processors.
Les say we have the case of sun4u (different MMU for each CPU). My guess
is that when you create a new process with threads less than the number
of physical cpus the address space is mapped to some context IDs at that
time; possibly the same context ID in case of not wraparound. But if
later a thread of a process migrates to a CPU that no other thread of
that process was scheduled before, it is possible that for that
processor the address space may be mapped to a different context ID.
yes, exactly. In fact, I would be surprised if any address space ended
up with the same context ids on different CPUS.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
