[PATCH V4] ARM: handle user space mapped pages in flush_kernel_dcache_page
Nicolas Pitre
nico at fluxnic.net
Tue May 28 13:52:27 EDT 2013
On Tue, 28 May 2013, Catalin Marinas wrote:
> On Sat, May 25, 2013 at 04:53:19AM +0100, Nicolas Pitre wrote:
> > On Thu, 23 May 2013, Catalin Marinas wrote:
> >
> > > An issue is that for kunmap_atomic() && VIVT we flush the same page
> > > twice. I don't think we should remove the cache flushing in
> > > __kunmap_atomic() for VIVT since not all kunmap_atomic() calls require
> > > flush_kernel_dcache_page() (unless we just assume that highmem && vivt
> > > don't work together).
> >
> > VIVT and highmem do work together. Highmem for ARM was in fact
> > developed on such a platform.
>
> Thanks for confirming. Do you remember why kunmap() doesn't (need to)
> flush the cache alias (for VIVT)? Or if it does, where?
kunmap() calls kunmap_high() which actually does not unmap anything but
only decrement a use count. The page is kept around in case it is
kmap()'d again, in which case the kmap() will be almost free and the
page still warm.
It is only when the kmap() for a new page runs out of free pkmap
entries that the unused but still mapped pages are unmapped. This
unmapping is done in flush_all_zero_pkmaps() where all the unused pages
are all unmapped at once. The cache for all those pages is flushed with
flush_cache_kmaps() which on ARM maps to flush_cache_all() when the
cache is VIVT.
Nicolas
More information about the linux-arm-kernel
mailing list