Date: Sun, 15 Dec 1996 11:54:22 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: toor@dyson.iquest.net (John S. Dyson) Cc: phk@critter.tfs.com, peter@spinner.dialix.com, dyson@freebsd.org, smp@freebsd.org, haertel@ichips.intel.com Subject: Re: some questions concerning TLB shootdowns in FreeBSD Message-ID: <199612151654.LAA05078@dyson.iquest.net> In-Reply-To: <199612151628.LAA05010@dyson.iquest.net> from "John S. Dyson" at Dec 15, 96 11:28:31 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >
> > In message <199612151003.SAA14741@spinner.DIALix.COM>, Peter Wemm writes:
> > >Poul-Henning Kamp wrote:
> > >> In message <199612150121.JAA12763@spinner.DIALix.COM>, Peter Wemm writes:
> > >>
> > >> >However, the shared address space code that I was working on in
> > >> >-current (for kernel assisted threading in the smp kernel) means
> > >> >that a single vmspace/pmap/etc can be shared among multiple processes
> > >> >and this changes the above picture since two cpu's can be using
> > >> >the user mode parts of the same page tables at once, one in executing
> > >> >in user mode, one in the kernel.
> > >>
^^^^^^^^^^^^^^^
> > >> But we could still have a per-cpu flags:
> > >> "I'm not in a shared address-space"
> > >>
> > >> Ie, this would only be set if the CPU was in userland in a non-threaded
> > >> process.
> > >
> > >eg, something like:
> > >if (is_userland && curproc->p_vmspace->vm_refcnt > 1)
> > > send_tlb_invalidate();
> >
> > Well more like:
> >
> > for (i=0;i<NCPU;i++)
> > if (is_userland(i) && curproc[i]->p_vmspace->vm_refcnt > 1)
> > send_tlb_invalidate(i);
> >
> This won't work because processes seldom have the entire address space
> shared (vm_refcnt.) I am sure that when we get true kernel multithreading
> that will not be true though. In order to test if a section of an
> address space is shared, you have to do something like this (and
> this can take LOTS of time.) (I might have levels of indirection
> off here, I am also not taking into account submaps -- which
> complicate the code further, by entailing recursively calling
> the map/object traversal again -- but recursion is a major
> no-no in the kernel, as we have found.)
>
Note that I do see that you were talking about shared address spaces,
but address spaces are already partially shared. To do the thing completely
requires traversing alot of the VM data structures. I would suggest
that a coarser grained scheme for pmap_update (invtlb) be considered in
the case of SMP. Also (Peter's ?) suggestion that we have individual
alternate page table's (and temporary mapping pages) for each CPU's
has merit.
It is likely that large numbers of TLB flushes could be eliminated
if the above were implemented. Since global TLB flushes are going to
be fairly expensive, let's minimize them -- but scanning the VM
data structures is going to be expensive no matter how we do it.
Note that I have put individual page invalidates into pmap -- we
need to usually remove those in the SMP code. (There are some
special mapping pages where we should probably continue doing
the page invalidates -- but those should also be per-cpu.)
John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612151654.LAA05078>