>-----Original Message----- >From: Kumar Gala [mailto:ga...@kernel.crashing.org] > >On Nov 17, 2009, at 1:10 AM, Li Yang wrote: > >> Rather than the original intelligent way, we grant user more freedom. >> This enables user to map cacheable memory not managed by Linux. >> >> Signed-off-by: Li Yang <le...@freescale.com> >> --- >> The only direct users of this function is fb_mmap() and >/dev/mem mmap. >> Although I'm not sure if anything is depending on the intelligent >> setting of cacheability. > >is there some reason to change this?
Because there is no way to set mapped memory as cacheable if the memory is not managed by Linux kernel. While, it's not rare in real system to allocate some dedicated memory to a certain application which is not managed by kernel and then mmap'ed the memory to the application. The memory should be cacheable but we can't map it to be cacheable due to this intelligent setting. And it is a big hit to the performance. Moreover, the standard O_SYNC flag suggest that user has the control over cacheablity, but actually we had not. - Leo > >- k > >> >> arch/powerpc/mm/mem.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index >> 579382c..0fd267e 100644 >> --- a/arch/powerpc/mm/mem.c >> +++ b/arch/powerpc/mm/mem.c >> @@ -101,7 +101,7 @@ pgprot_t phys_mem_access_prot(struct file *file, >> unsigned long pfn, >> if (ppc_md.phys_mem_access_prot) >> return ppc_md.phys_mem_access_prot(file, pfn, >size, vma_prot); >> >> - if (!page_is_ram(pfn)) >> + if (file->f_flags & O_SYNC) >> vma_prot = pgprot_noncached(vma_prot); >> >> return vma_prot; >> -- >> 1.6.4 >> >> _______________________________________________ >> Linuxppc-dev mailing list >> Linuxppc-dev@lists.ozlabs.org >> https://lists.ozlabs.org/listinfo/linuxppc-dev > > > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
