Re: sparc64 question.. Anyone out there?

At 12:30 PM -0700 5/19/04, Julian Elischer wrote:
>Is there anyone out there who really understands this?

I do not, but I will be happy to cheer from the sidelines and
hope that someone else does understand it...   :-)

>On Tue, 18 May 2004, Julian Elischer wrote:
>
>  > >
>>  > To quote from the commit log:
>  > >    date: 2002/06/24 15:48:01;  author: jake;
>  > >    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.

-- 
Garance Alistair Drosehn            =   gad_at_gilead.netel.rpi.edu
Senior Systems Programmer           or  gad_at_freebsd.org
Rensselaer Polytechnic Institute    or  drosih_at_rpi.edu