svn commit: r195820 - in head/sys/amd64: amd64 include

[Kostik Belousov]

On Wed, Jul 22, 2009 at 02:44:52PM -0400, Jung-uk Kim wrote:
> On Wednesday 22 July 2009 10:32 am, Konstantin Belousov wrote:
> > Author: kib
> > Date: Wed Jul 22 14:32:38 2009
> > New Revision: 195820
> > URL: http://svn.freebsd.org/changeset/base/195820
> >
> > Log:
> >   When the page caching attributes are changed, after new mapping
> > is established, OS shall flush the caches on all processors that
> > may have used the mapping previously. This operation is not needed
> > if processors support self-snooping. If not, but clflush
> > instruction is implemented on the CPU, series of the clflush can be
> > used on the mapping region. Otherwise, we have to flush the whole
> > cache. The later operation is very expensive, and AMD-made CPUs do
> > not have self-snooping.
> >
> >   Implement cache flush for remapped region by using clflush for
> > amd64, when supported by CPU.
> 
> --- >8 --- SKIP --- >8 ---
> 
> > @@ -267,6 +274,13 @@ outw(u_int port, u_short data)
> >  }
> >
> >  static __inline void
> > +mfence(void)
> > +{
> > +
> > +	__asm__ __volatile("mfence" : : : "memory");
> > +}
> > +
> > +static __inline void
> >  ia32_pause(void)
> >  {
> >  	__asm __volatile("pause");
> 
> Is there any reason why you want mfence() instead of mb() from 
> machine/atomic.h?

Char-to-char equal implementation of pmap_invalidate_cache_range()
is developed for i386. Note that mb() is a barrier, while Intel
notes that clflush only ordered with mfence. On i386, mb() is
locked nop.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20090722/d615a734/attachment.pgp