[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2f11576a0901290435p1bdb41b3o7171384250b93c08@mail.gmail.com>
Date: Thu, 29 Jan 2009 21:35:36 +0900
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: Lee Schermerhorn <Lee.Schermerhorn@...com>
Cc: MinChan Kim <minchan.kim@...il.com>, linux mm <linux-mm@...ck.org>,
linux kernel <linux-kernel@...r.kernel.org>,
Nick Piggin <npiggin@...e.de>
Subject: Re: [BUG] mlocked page counter mismatch
Hi
> I think I see it. In try_to_unmap_anon(), called from try_to_munlock(),
> we have:
>
> list_for_each_entry(vma, &anon_vma->head, anon_vma_node) {
> if (MLOCK_PAGES && unlikely(unlock)) {
> if (!((vma->vm_flags & VM_LOCKED) &&
> !!! should be '||' ? ^^
> page_mapped_in_vma(page, vma)))
> continue; /* must visit all unlocked vmas */
> ret = SWAP_MLOCK; /* saw at least one mlocked vma */
> } else {
> ret = try_to_unmap_one(page, vma, migration);
> if (ret == SWAP_FAIL || !page_mapped(page))
> break;
> }
> if (ret == SWAP_MLOCK) {
> mlocked = try_to_mlock_page(page, vma);
> if (mlocked)
> break; /* stop if actually mlocked page */
> }
> }
>
> or that clause [under if (MLOCK_PAGES && unlikely(unlock))]
> might be clearer as:
>
> if ((vma->vm_flags & VM_LOCKED) && page_mapped_in_vma(page, vma))
> ret = SWAP_MLOCK; /* saw at least one mlocked vma */
> else
> continue; /* must visit all unlocked vmas */
>
> Do you agree?
Hmmm.
I don't think so.
> if (!((vma->vm_flags & VM_LOCKED) &&
> page_mapped_in_vma(page, vma)))
> continue; /* must visit all unlocked vmas */
is already equivalent to
> if ((vma->vm_flags & VM_LOCKED) && page_mapped_in_vma(page, vma))
> ret = SWAP_MLOCK; /* saw at least one mlocked vma */
> else
> continue; /* must visit all unlocked vmas */
> And, I wonder if we need a similar check for
> page_mapped_in_vma(page, vma) up in try_to_unmap_one()?
because page_mapped_in_vma() can return 0 if vma is anon vma only.
In the other word,
struct adress_space (for file) gurantee that unrelated vma doesn't chained.
but struct anon_vma (for anon) doesn't gurantee that unrelated vma
doesn't chained.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists