lkml.org 
[lkml]   [2017]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC v5 04/11] mm: VMA sequence count
On Tue, Aug 08, 2017 at 04:29:32PM +0530, Anshuman Khandual wrote:
> On 06/16/2017 11:22 PM, Laurent Dufour wrote:
> > From: Peter Zijlstra <peterz@infradead.org>
> >
>
> First of all, please do mention that its adding a new element into the
> vm_area_struct which will act as a sequential lock element and help
> in navigating page fault without mmap_sem lock.

You're not making sense, there is no lock, and the lines below clearly
state we're adding a sequence count.

>
> > Wrap the VMA modifications (vma_adjust/unmap_page_range) with sequence
> > counts such that we can easily test if a VMA is changed
>
> Yeah true.
>
> >
> > The unmap_page_range() one allows us to make assumptions about
> > page-tables; when we find the seqcount hasn't changed we can assume
> > page-tables are still valid.
>
> Because unmap_page_range() is the only function which can tear it down ?
> Or is there any other reason for this assumption ?

Yep.

> >
> > The flip side is that we cannot distinguish between a vma_adjust() and
> > the unmap_page_range() -- where with the former we could have
> > re-checked the vma bounds against the address.
>
> Distinguished for what purpose ?

It states. If you know its a vma_adjust we could just check if we're
inside the new boundaries and continue. But since we cannot, we have to
assume the worst and bail.

\
 
 \ /
  Last update: 2017-08-08 13:04    [W:0.047 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site