Re: get_user_pages() cache issues on ARM

[James Bottomley <James.Bottomley@SteelEye.com>]

On Sat, 2006-09-30 at 19:18 +0200, Miklos Szeredi wrote:
> Added James Bottomley to the CC.  He designed this interface, and he
> explained to me how it's supposed to work, but I since forgot.
> 
> James, do you have some memory of these issues?

I can try, but the problems were very parisc specific.

> > The questions I have are:
> > 
> > - where do these pages that get_user_pages() finds and calls flush_anon_page()
> >   on come from?

Anonymous pages are non-file backed pages.  Fuse has them because it
uses non file backed buffers to operate the user level filesystem
(basically any memory you malloc at user level can end up as an
anonymous page).

> > - why is the current ARM flush_dcache_page() (which is also called after
> >   flush_anon_page()) not sufficient?

I think you do the same as we do on parisc: traverse the
page_mapping(page) list and flush.  Unfortunately, anonymous pages don't
have entries in the page_mapping(page) list (because they're not file
backed), so our flush_dcache_page() wasn't flushing them, hence the need
for an additional API for fuse.

if you have an archive of linux-arch, the original discussion is under
the subject

Potential problem with the page_mapping macro and flush_dcache_page()

and begins on 19 March 2006

> > - if we implement flush_anon_page() does that mean that we end up flushing
> >   multiple times in some circumstances?  If so, how do we avoid this?

In theory no, because the way I coded the parisc version, it ignores
non-anon pages, which are flushed by flush_dcache_page(); but it would
depend on how you implement this.

James