Re: [patch 2/8] x86 PAT: set VM_PFNMAP flag in vm_insert_pfn

[Ingo Molnar <mingo@elte.hu>]

* Nick Piggin <npiggin@suse.de> wrote:

> On Fri, Nov 14, 2008 at 01:35:38PM -0800, Pallipadi, Venkatesh wrote:
> > 
> > 
> > >-----Original Message-----
> > >From: Nick Piggin [mailto:npiggin@suse.de]
> > >Sent: Thursday, November 13, 2008 6:06 PM
> > >To: Pallipadi, Venkatesh
> > >Cc: Ingo Molnar; Thomas Gleixner; H Peter Anvin; Hugh Dickins;
> > >Roland Dreier; Jesse Barnes; Jeremy Fitzhardinge; Arjan van de
> > >Ven; linux-kernel@vger.kernel.org; Siddha, Suresh B
> > >Subject: Re: [patch 2/8] x86 PAT: set VM_PFNMAP flag in vm_insert_pfn
> > >
> > >On Thu, Nov 13, 2008 at 10:47:23AM -0800, Pallipadi, Venkatesh wrote:
> > >>
> > >> Yes. It does. But, it calls a lower level insert_pfn()
> > >function. The lower
> > >> level insert_pfn() does not have any bug checks. But the higher level
> > >> vm_insert_pfn() checks for PFNMAP or MIXEDMAP.
> > >
> > >Yes, but is there anything extra you need to check for cache aliases in
> > >MIXEDMAP mappings?
> > >
> > 
> > Yes. We need additional things to track MIXEDMAP and we are looking at that.
> > But, that is slightly more trickier than the general PFNMAP case. And
> > only in-tree user of MIXEDMAP is xip and that too it only uses it for
> > regular WB mapping. So, we thought we should fix the more common case
> > first here.
> > 
> > With MIXEDMAP there is no way whether to distinguish whether insert_pfn
> > Or insert_page was used while looking at VMA. We can probably use PFNMAP
> > in addition to MIXEDMAP to indicate that, which will make things easier.
> 
> It's difficult because it can have either method for a single VMA, and
> a given address in the vma may even change over time (not with current
> code in kernel AFAIKS, but AXFS eventually might get to that point).
> 
> 
> > But, we are still looking at that and trying to understand the change
> > implication.
> 
> OK: now I understand correctly. Getting PFNMAP working is an important
> first step. I agree.

Venki, a patch logistics sidenote: the final mm/* bits of this 
patchset need acks from MM folks - Andrew, Nick or Hugh - we cannot 
just queue them up in the x86/pat tree without agreement from MM 
maintainers.

	Ingo