Re: [PATCH] Document Linux's memory barriers [try #2]
- From: "David S. Miller" <davem@xxxxxxxxxxxxx>
- Date: Wed, 08 Mar 2006 14:23:26 -0800 (PST)
From: Paul Mackerras <paulus@xxxxxxxxx>
Date: Thu, 9 Mar 2006 09:01:57 +1100
On PPC machines, the PTE has a bit called G (for Guarded) which
indicates that the memory mapped by it has side effects. It prevents
the CPU from doing speculative accesses (i.e. the CPU can't send out a
load from the page until it knows for sure that the program will get
to that instruction) and from prefetching from the page.
The kernel sets G=1 on MMIO and PIO pages in general, as you would
expect, although you can get G=0 mappings for framebuffers etc. if you
ask specifically for that.
Sparc64 has a similar PTE bit called "E" for "side-Effect".
And we also do the same thing as powerpc for framebuffers.
Note that on sparc64 in our asm/io.h PIO/MMIO accessor macros
we use physical addresses, so we don't have to map anything
in ioremap(), and use a special address space identifier on
the loads and stores that indicates "E" behavior is desired.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- [PATCH] Document Linux's memory barriers [try #2]
- From: David Howells
- Re: [PATCH] Document Linux's memory barriers [try #2]
- From: Alan Cox
- Re: [PATCH] Document Linux's memory barriers [try #2]
- From: Paul Mackerras
- [PATCH] Document Linux's memory barriers [try #2]
- Prev by Date: [BUG] 2.6.16-rc5-mm2/3 : oops on rmmod snd-ens1371
- Next by Date: Re: [patch 1/4] net: percpufy frequently used vars -- add percpu_counter_mod_bh
- Previous by thread: Re: [PATCH] Document Linux's memory barriers [try #2]
- Next by thread: Re: [PATCH] Document Linux's memory barriers [try #2]
- Index(es):
Relevant Pages
|
