Jim Glent wrote:
Although your hints helped me much to understand what going on inside there,
there does remain one obscure point...
As far as I can see, when resume() or _resume_from_idle() is called, the stored (gnum | cnum) context for
the process is loaded from curthread->t_procp->p_as->a_hat->sfmmu_ctxts[cpu->cpu_mmu_idx]
in sfmmu_alloc_ctx(). If a thread's associated proc bears an invalid context, then sfmmu_alloc_ctx()
assigns the next available context number from cpu->cpu_mmu_ctxp->mmu_cnum. For sun4u machines,
sfmmu_cpu_init() specifies, through sfmmu_cpuid_to_mmu_ctx_info(), that cpu->cpu_mmu_idx =
cpu->cpu_seqid.
All that indicates that when a thread without a good context number is switched
to, it will get a unique context number for the CPU it is about to run. So,
threads within the same process may have different contexts, even though they
actually refer to the same address space. Also, when a thread migrates to
another CPU, it will get a brand new context number, unless it has also ran
previously there. Is that all right?
Yes I think that is all correct. It did not used to be that way - it used to
be that
all threads in a process would use the same hardware context number on all
cpus; that
could lead to huge crosscall issues on tlb demaps and a year or two ago a
project
was putback to allow different hardware context id per cpu within a process.
I don't know the implementation details of that project.
What bothers me is that at times threads with different kthread_t.t_tid's but
same contexts seem to run on the same CPU. Can a thread's tid change during its
execution?
The term context is horribly overloaded.
In one sense "context" is the register state etc of a running thread. If we
wish to
stop running a thread and run another then we must save this context and restore
that for the incoming thread. That's a "context switch" but it's not
necessarily
a change in mmu/hardware context.
Every process has it's own address space, and the kernel has its own address
space.
All threads within an address process (or the kernel) share that address space.
The hardware context (or mmu context) maps on to a single address space.
So all threads executing on a single cpu (well at least all cpus served by the
same mmus) of the same process use the same hardware context.
Somewhere in the sparc docs is a nice picture of how address translation works
and how context fits in. Essentially the current context (or that selected
by the ASI implicit or explicit in the instruction) is tacked on to the
virtual address that is presented to the mmu for translation, so that
an address x in one address space is different to the same x in another
address space.
Hope that helps
Gavin
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
