Date: Wed, 19 May 2004 16:30:04 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Julian Elischer <julian@elischer.org>, Thomas Moestl <tmm@freebsd.org> Cc: sparc64@freebsd.org Subject: Re: sparc64 question.. Anyone out there? Message-ID: <p06020403bcd172838f71@[128.113.24.47]> In-Reply-To: <Pine.BSF.4.21.0405191228190.41838-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0405191228190.41838-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06020403bcd172838f71>