From: "Stone Wang" <pwstone@gmail.com>
To: "Christoph Lameter" <clameter@sgi.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH][0/8] (Targeting 2.6.17) Posix memory locking and balanced mlock-LRU semantic
Date: Tue, 21 Mar 2006 10:20:12 -0500 [thread overview]
Message-ID: <bc56f2f0603210720q332b0fdbu@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0603200923560.24138@schroedinger.engr.sgi.com>
Checked, mlocked pages dont take part in swapping-writeback,
unlike normal mmaped pages :
linux-2.6.16/mm/rmap.c
try_to_unmap_one()
603 if ((vma->vm_flags & VM_LOCKED) ||
604 (ptep_clear_flush_young(vma, address, pte)
605 && !ignore_refs)) {
606 ret = SWAP_FAIL;
607 goto out_unmap;
608 }
609
610 /* Nuke the page table entry. */
611 flush_cache_page(vma, address, page_to_pfn(page));
612 pteval = ptep_clear_flush(vma, address, pte);
613
614 /* Move the dirty bit to the physical page now the pte is gone. */
615 if (pte_dirty(pteval))
616 set_page_dirty(page);
For VM_LOCKED page, it goes back(line 607) without set_page_dirty(line 616).
2006/3/20, Christoph Lameter <clameter@sgi.com>:
> On Mon, 20 Mar 2006, Stone Wang wrote:
>
> > 2. More consistent LRU semantics in Memory Management.
> > Mlocked pages is placed on a separate LRU list: Wired List.
> > The pages dont take part in LRU algorithms,for they could never be swapped,
> > until munlocked.
>
> This also implies that dirty bits of the pte for mlocked pages are never
> checked.
>
> Currently light swapping (which is very common) will scan over all pages
> and move the dirty bits from the pte into struct page. This may take
> awhile but at least at some point we will write out dirtied pages.
>
> The result of not scanning mlocked pages will be that mmapped files will
> not be updated unless either the process terminates or msync() is called.
>
>
WARNING: multiple messages have this Message-ID (diff)
From: "Stone Wang" <pwstone@gmail.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH][0/8] (Targeting 2.6.17) Posix memory locking and balanced mlock-LRU semantic
Date: Tue, 21 Mar 2006 10:20:12 -0500 [thread overview]
Message-ID: <bc56f2f0603210720q332b0fdbu@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0603200923560.24138@schroedinger.engr.sgi.com>
Checked, mlocked pages dont take part in swapping-writeback,
unlike normal mmaped pages :
linux-2.6.16/mm/rmap.c
try_to_unmap_one()
603 if ((vma->vm_flags & VM_LOCKED) ||
604 (ptep_clear_flush_young(vma, address, pte)
605 && !ignore_refs)) {
606 ret = SWAP_FAIL;
607 goto out_unmap;
608 }
609
610 /* Nuke the page table entry. */
611 flush_cache_page(vma, address, page_to_pfn(page));
612 pteval = ptep_clear_flush(vma, address, pte);
613
614 /* Move the dirty bit to the physical page now the pte is gone. */
615 if (pte_dirty(pteval))
616 set_page_dirty(page);
For VM_LOCKED page, it goes back(line 607) without set_page_dirty(line 616).
2006/3/20, Christoph Lameter <clameter@sgi.com>:
> On Mon, 20 Mar 2006, Stone Wang wrote:
>
> > 2. More consistent LRU semantics in Memory Management.
> > Mlocked pages is placed on a separate LRU list: Wired List.
> > The pages dont take part in LRU algorithms,for they could never be swapped,
> > until munlocked.
>
> This also implies that dirty bits of the pte for mlocked pages are never
> checked.
>
> Currently light swapping (which is very common) will scan over all pages
> and move the dirty bits from the pte into struct page. This may take
> awhile but at least at some point we will write out dirtied pages.
>
> The result of not scanning mlocked pages will be that mmapped files will
> not be updated unless either the process terminates or msync() is called.
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-03-21 15:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-20 13:35 [PATCH][0/8] (Targeting 2.6.17) Posix memory locking and balanced mlock-LRU semantic Stone Wang
2006-03-20 13:41 ` Arjan van de Ven
2006-03-20 13:41 ` Arjan van de Ven
2006-03-20 23:52 ` Nate Diller
2006-03-20 23:52 ` Nate Diller
2006-03-21 7:10 ` Arjan van de Ven
2006-03-21 7:10 ` Arjan van de Ven
2006-03-21 12:24 ` Nick Piggin
2006-03-21 12:24 ` Nick Piggin
2006-03-20 17:27 ` Christoph Lameter
2006-03-20 17:27 ` Christoph Lameter
2006-03-21 5:23 ` Stone Wang
2006-03-21 5:23 ` Stone Wang
2006-03-21 15:20 ` Stone Wang [this message]
2006-03-21 15:20 ` Stone Wang
2006-03-24 4:45 ` Rik van Riel
2006-03-24 4:45 ` Rik van Riel
2006-03-21 12:20 ` Nick Piggin
2006-03-21 12:20 ` Nick Piggin
2006-03-24 15:05 ` Stone Wang
2006-03-24 15:05 ` Stone Wang
2006-03-24 16:57 ` Nick Piggin
2006-03-24 16:57 ` Nick Piggin
2006-03-24 14:36 ` Andi Kleen
2006-03-24 14:36 ` Andi Kleen
2006-03-24 14:54 ` Stone Wang
2006-03-24 14:54 ` Stone Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bc56f2f0603210720q332b0fdbu@mail.gmail.com \
--to=pwstone@gmail.com \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.