Date: Wed, 19 May 2004 12:30:01 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Thomas Moestl <tmm@FreeBSD.org> Cc: sparc64@freebsd.org Subject: Re: sparc64 question.. Anyone out there? Message-ID: <Pine.BSF.4.21.0405191228190.41838-100000@InterJet.elischer.org> In-Reply-To: <Pine.BSF.4.21.0405181248180.41838-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Is there anyone out there who really understands this?
On Tue, 18 May 2004, Julian Elischer wrote:
>
> looking at this code again and the description as to why it is there..
>
>
> On Mon, 10 May 2004, Thomas Moestl wrote:
>
> > On Sun, 2004/05/09 at 15:44:40 -0700, Julian Elischer wrote:
> > > in vm_machdep.c the sparc64 code has
> > > void
> > > cpu_sched_exit(struct thread *td)
> > > {
> > > struct vmspace *vm;
> > > struct pcpu *pc;
> > > struct proc *p;
> > >
> > > mtx_assert(&sched_lock, MA_OWNED);
> > >
> > > p = td->td_proc;
> > > vm = p->p_vmspace;
> > > if (vm->vm_refcnt > 1)
> > > return;
> > > SLIST_FOREACH(pc, &cpuhead, pc_allcpu) {
> > > if (pc->pc_vmspace == vm) {
> > > vm->vm_pmap.pm_active &= ~pc->pc_cpumask;
> > > vm->vm_pmap.pm_context[pc->pc_cpuid] = -1;
> > > pc->pc_vmspace = NULL;
> > > }
> > > }
> > > }
> > >
> > >
> > >
> > > This is thw only architecture that has this..
> > > What does it do? And what does it have to do with the scheduler?
>
> to answer question 2,,
> nothing.. in my sources I renamed it to cpu_exit2()
>
>
> >
> > To quote from the commit log:
> > date: 2002/06/24 15:48:01; author: jake; state: Exp; lines: +1 -0
> > Add an MD callout like cpu_exit, but which is called after sched_lock is
> > obtained, when all other scheduling activity is suspended. This is needed
> > on sparc64 to deactivate the vmspace of the exiting process on all cpus.
> > Otherwise if another unrelated process gets the exact same vmspace structure
> > allocated to it (same address), its address space will not be activated
> > properly. This seems to fix some spontaneous signal 11 problems with smp
> > on sparc64.
> >
> > To elaborate on that a bit:
> > The sparc64 cpu_switch() has an optimization to avoid needlessly
> > invalidating TLB entries: when we switch to a kernel thread, we need
> > not switch VM contexts at all, and do with whatever vmspace was active
> > before. When we switch to a thread that has the vmspace that is
> > already in use currently, we need not load a new context register
> > value (which is analog to flushing the TLB).
> >
> > We identify vmspaces by their pointers for this purpose, so there can
> > be a race between freeing the struct vmspace by wait()ing (on another
> > processor) and switching to another thread (on the first
> > processor). Specifically, the first processor could be switching to a
> > newly created thread that has the same struct vmspace that was just
> > freed, so we would mistakenly assume that we need not bother loading
> > the context register, and continue using outdated TLB entries.
> >
> > To prevent this, cpu_sched_exit() zeros the respective PCPU variables
> > holding the active vmspace if it is going to be destroyed, so it will
> > never match any other during the next cpu_switch().
>
> I'm not convinced that this is valid..
> consider..
> When you cycle through the processors above and remove the pointers to
> the vmspace, then proceed to destroy this vmspace, there is nothing done
> to make sure that the other procerssors are actually
> not USING the page tables etc. associated with the vmspace.
>
> If we reclame the page tables.. surely there is a danger that another
> cpu by still be using them?
>
> I think that even "temporary" users of vmspaces, such as kernel threads,
> should have reference counts and be capable of freeing the vmspace
> should it go to 0 when they complete using it.
>
>
>
>
> >
> > - Thomas
> >
> > --
> > Thomas Moestl <t.moestl@tu-bs.de> http://www.tu-bs.de/~y0015675/
> > <tmm@FreeBSD.org> http://people.FreeBSD.org/~tmm/
> > "I try to make everyone's day a little more surreal."
> > -- Calvin and Hobbes
> > _______________________________________________
> > freebsd-current@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
> >
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0405191228190.41838-100000>