[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1333495881.12400.19.camel@sbsiddha-desk.sc.intel.com>
Date: Tue, 03 Apr 2012 16:31:21 -0700
From: Suresh Siddha <suresh.b.siddha@...el.com>
To: Konstantin Khlebnikov <khlebnikov@...nvz.org>
Cc: Konstantin Khlebnikov <koct9i@...il.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andi Kleen <andi@...stfloor.org>,
Pallipadi Venkatesh <venki@...gle.com>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Nick Piggin <npiggin@...nel.dk>
Subject: Re: [x86 PAT PATCH 1/2] x86, pat: remove the dependency on
'vm_pgoff' in track/untrack pfn vma routines
On Tue, 2012-04-03 at 09:37 +0400, Konstantin Khlebnikov wrote:
> Suresh Siddha wrote:
> > 'pfn' argument for track_pfn_vma_new() can be used for reserving the attribute
> > for the pfn range. No need to depend on 'vm_pgoff'
> >
> > Similarly, untrack_pfn_vma() can depend on the 'pfn' argument if it
> > is non-zero or can use follow_phys() to get the starting value of the pfn
> > range.
> >
> > Also the non zero 'size' argument can be used instead of recomputing
> > it from vma.
> >
> > This cleanup also prepares the ground for the track/untrack pfn vma routines
> > to take over the ownership of setting PAT specific vm_flag in the 'vma'.
> >
> > Signed-off-by: Suresh Siddha<suresh.b.siddha@...el.com>
> > Cc: Venkatesh Pallipadi<venki@...gle.com>
> > Cc: Konstantin Khlebnikov<khlebnikov@...nvz.org>
> > ---
> > arch/x86/mm/pat.c | 30 +++++++++++++++++-------------
> > 1 files changed, 17 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> > index f6ff57b..617f42b 100644
> > --- a/arch/x86/mm/pat.c
> > +++ b/arch/x86/mm/pat.c
> > @@ -693,14 +693,10 @@ int track_pfn_vma_new(struct vm_area_struct *vma, pgprot_t *prot,
> > unsigned long pfn, unsigned long size)
> > {
> > unsigned long flags;
> > - resource_size_t paddr;
> > - unsigned long vma_size = vma->vm_end - vma->vm_start;
> >
> > - if (is_linear_pfn_mapping(vma)) {
> > - /* reserve the whole chunk starting from vm_pgoff */
> > - paddr = (resource_size_t)vma->vm_pgoff<< PAGE_SHIFT;
> > - return reserve_pfn_range(paddr, vma_size, prot, 0);
> > - }
> > + /* reserve the whole chunk starting from pfn */
> > + if (is_linear_pfn_mapping(vma))
> > + return reserve_pfn_range(pfn, size, prot, 0);
>
> you mix here pfn and paddr: old code passes paddr as first argument of reserve_pfn_range().
oops. That was my oversight. I updated the two patches to address this.
Also I cleared VM_PAT flag as part of the untrack_pfn_vma(), so that the
use cases (like the i915 case) which just evict the pfn's (by using
unmap_mapping_range) with out actually removing the vma will do the
free_pfn_range() only when it is required.
Attached (to this e-mail) are the -v2 versions of the PAT patches. I
tested these on my SNB laptop.
thanks,
suresh
View attachment "0001-x86-pat-remove-the-dependency-on-vm_pgoff-in-track-u.patch" of type "text/x-patch" (2890 bytes)
View attachment "0002-mm-x86-PAT-rework-linear-pfn-mmap-tracking.patch" of type "text/x-patch" (8404 bytes)
Powered by blists - more mailing lists