On Wed, Sep 26, 2012 at 6:40 PM, David Rientjes wrote:
>
> Ok, sounds good. If there's no objection, I'd like to ask Andrew to apply
> this to -mm and remove the cc to sta...@vger.kernel.org since the
> mlock_vma_page() problem above is separate and doesn't conflict with this
> code, so I'll send
Hi David,
On Wed, Sep 19, 2012 at 06:19:27PM -0700, David Rientjes wrote:
> + if ((flags & FOLL_MLOCK) && (vma->vm_flags & VM_LOCKED)) {
> + if (page->mapping && trylock_page(page)) {
> + lru_add_drain();
> + if (page->mapping)
> +
On Wed, 26 Sep 2012, David Rientjes wrote:
> On Wed, 19 Sep 2012, Hugh Dickins wrote:
>
> > Good catch, and the patch looks right to me, as far as it goes:
> > but does it go far enough?
> >
> > I hesitate because it looks as if the NR_MLOCK zone page state is
> > maintained (with incs and decs)
On Wed, 19 Sep 2012, Hugh Dickins wrote:
> Good catch, and the patch looks right to me, as far as it goes:
> but does it go far enough?
>
> I hesitate because it looks as if the NR_MLOCK zone page state is
> maintained (with incs and decs) in ignorance of THP; so although
> you will be correcting
On Wed, 18 Sep 2012, David Rientjes wrote:
> When a transparent hugepage is mapped and it is included in an mlock()
> range, follow_page() incorrectly avoids setting the page's mlock bit and
> moving it to the unevictable lru.
>
> This is evident if you try to mlock(), munlock(), and then mlock()
When a transparent hugepage is mapped and it is included in an mlock()
range, follow_page() incorrectly avoids setting the page's mlock bit and
moving it to the unevictable lru.
This is evident if you try to mlock(), munlock(), and then mlock() a
range again. Currently:
#define MAP_SIZE
6 matches
Mail list logo
