Unnecessary cache-line flush on page table updates ?
Russell King - ARM Linux
linux at arm.linux.org.uk
Tue Jul 5 05:46:52 EDT 2011
On Tue, Jul 05, 2011 at 10:26:00AM +0100, Catalin Marinas wrote:
> On Mon, Jul 04, 2011 at 10:55:07PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Jul 04, 2011 at 12:13:38PM +0100, Russell King - ARM Linux wrote:
> > > As far as the BTB goes, I wonder if we can postpone that for user TLB
> > > ops by setting a TIF_ flag and checking that before returning to userspace.
> > > That would avoid having to needlessly destroy the cached branch information
> > > for kernel space while looping over the page tables. The only other place
> > > that needs to worry about that is module_alloc() and vmap/vmalloc with
> > > PROT_KERNEL_EXEC, all of which can be done in flush_cache_vmap().
> >
> > Actually, we don't need to do BTC invalidate in flush_cache_vmap(),
> > but we do need to do a dsb+isb.
>
> Why would we need an ISB?
Because the ARM ARM tells us that we must do a dsb+isb to ensure that
instructions are visible to the instruction stream after a change to
the page tables.
I've since added the dsb+isbs back to the TLB ops because the ARM ARM
is qutie explicit that both are required to ensure that explicit
accesses see the effect of the TLB operation. To me it is rather
perverse that an ISB is required to ensure that this sequence works:
write page table entry
clean
dsb
flush tlb entry
dsb
isb
read/write new page
but the ARM ARM is quite explicit that this sequence is insufficient:
write page table entry
clean
dsb
flush tlb entry
dsb
read/write new page
to ensure visibility of the new page.
I suspect that the ARM ARM is wrong here - and the ISB is only required
if you're going to be executing from the new page. Maybe that's already
been fixed? Is there an update to DDI0406B?
More information about the linux-arm-kernel
mailing list