Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Dec 1996 09:35:30 +0800
From:      Peter Wemm <peter@spinner.dialix.com>
To:        Poul-Henning Kamp <phk@critter.tfs.com>
Cc:        dyson@freebsd.org, smp@freebsd.org, haertel@ichips.intel.com
Subject:   Re: some questions concerning TLB shootdowns in FreeBSD 
Message-ID:  <199612150135.JAA13241@spinner.DIALix.COM>
In-Reply-To: Your message of "Sat, 14 Dec 1996 21:06:28 %2B0100." <5557.850593988@critter.tfs.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
> In message <199612141838.NAA00208@dyson.iquest.net>, "John S. Dyson" writes:
> >The way that I see it, is that the current pmap code is highly optimized
> >for single processor operation.  If I was you, I would try to just
> >try to get something working correctly algorithmically -- almost ignoring
> >performance issues.  Of course, when performance is easy -- go for that
> >also.
> >
> >Alot of things like single page invalidates inside of loops appear that
> >they could be evil for multi-processor applications (imagine an inter-
> >processor interrupt for every loop!?!?.)  I think that you (we or us),
> >will have to look at the performance for the SMP direction, and it
> >might even entail large differences in pmap eventually.  Hopefully,
> >we will all be able to isolate the differences for the maintenance of
> >sanity :-).
> 
> The crucial thing, as far as I can see, is to find out >if< we need to
> tell the other CPU's about this change to the pagetables.  For a 2cpu
> system the penalty of stopping the other CPU is still within bounds
> of the reasonable, but stopping three CPUs needlessly is not a good idea.

Yes..  Also, there seem to be cases where the cpu needs to invalidate
on entry to the kernel, but does not need to be kicked via an IPI.
eg: if we change the kernel page tables, other cpu's running user
code at the time do not need to flush until they actually try to
enter the kernel.

We should replace the existing simplistic code with a group of bitmaps that
are accessed via atomic bit-set/clear and bit-test-and-set/clear so that
we can syncronise deferred TLB flushes and callins for common PTE's.

Cheers,
-Peter



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612150135.JAA13241>