From: Johannes Weiner <hannes@saeurebad.de>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org
Subject: Re: mm-more-likely-reclaim-madv_sequential-mappings.patch
Date: Sat, 18 Oct 2008 12:45:38 +0200 [thread overview]
Message-ID: <87fxmu41wt.fsf@saeurebad.de> (raw)
In-Reply-To: <200810181230.33688.nickpiggin@yahoo.com.au> (Nick Piggin's message of "Sat, 18 Oct 2008 12:30:33 +1100")
Nick Piggin <nickpiggin@yahoo.com.au> writes:
> On Saturday 18 October 2008 03:51, Johannes Weiner wrote:
>> Nick Piggin <nickpiggin@yahoo.com.au> writes:
>> > On Friday 17 October 2008 04:04, Rik van Riel wrote:
>> >> Nick Piggin wrote:
>> >> > ClearPageReferenced I don't know if it should be cleared like this.
>> >> > PageReferenced is more of a bit for the mark_page_accessed state
>> >> > machine, rather than the pte_young stuff. Although when unmapping, the
>> >> > latter somewhat collapses back to the former, but I don't know if
>> >> > there is a very good reason to fiddle with it here.
>> >> >
>> >> > Ignoring the young bit in the pte for sequential hint maybe is OK (and
>> >> > seems to be effective as per the benchmarks). But I would prefer not
>> >> > to merge the PageReferenced parts unless they get their own
>> >> > justification.
>> >>
>> >> Unless we clear the PageReferenced bit, we will still activate
>> >> the page - even if its only access came through a sequential
>> >> mapping.
>> >>
>> >> Faulting the page into the sequential mapping ends up setting
>> >> PageReferenced, IIRC.
>> >
>> > Yes I see. But that's stupid because then you can end up putting a
>> > sequential mapping on a page, and cause that to deactivate somebody
>> > else's references... and the deactivation _only_ happens if the
>> > sequential mapping pte is young and the page happens not to be
>> > active, which is totally arbitrary.
>>
>> Another access would mean another young PTE, which we will catch as a
>> proper reference sooner or later while walking the mappings, no?
>
> No. Another access could come via read/write, or be subsequently unmapped
> and put into PG_referenced.
read/write use mark_page_accessed(), so after having two accesses, the
page is already active. If it's not and we find an access through a
sequential mapping, we should be safe to clear PG_referenced.
So the combination of young pte, page not active and scanning a
sequential mapping is not an arbitrary condition at all.
The only incorrect behaviour I can see here is what you already pointed
out: zap_pte_range() should mark_page_accessed().
Hannes
--
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:[~2008-10-18 10:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-15 23:22 mm-more-likely-reclaim-madv_sequential-mappings.patch Andrew Morton
2008-10-16 1:30 ` mm-more-likely-reclaim-madv_sequential-mappings.patch KOSAKI Motohiro
2008-10-16 6:01 ` mm-more-likely-reclaim-madv_sequential-mappings.patch KOSAKI Motohiro
2008-10-16 6:06 ` mm-more-likely-reclaim-madv_sequential-mappings.patch Andrew Morton
2008-10-16 6:22 ` mm-more-likely-reclaim-madv_sequential-mappings.patch KOSAKI Motohiro
2008-10-16 6:31 ` mm-more-likely-reclaim-madv_sequential-mappings.patch Andrew Morton
2008-10-16 6:38 ` mm-more-likely-reclaim-madv_sequential-mappings.patch KOSAKI Motohiro
2008-10-16 8:07 ` mm-more-likely-reclaim-madv_sequential-mappings.patch KOSAKI Motohiro
2008-10-16 6:09 ` mm-more-likely-reclaim-madv_sequential-mappings.patch KOSAKI Motohiro
2008-10-16 13:43 ` mm-more-likely-reclaim-madv_sequential-mappings.patch Nick Piggin
2008-10-16 17:04 ` mm-more-likely-reclaim-madv_sequential-mappings.patch Rik van Riel
2008-10-17 2:21 ` mm-more-likely-reclaim-madv_sequential-mappings.patch Nick Piggin
2008-10-17 5:37 ` mm-more-likely-reclaim-madv_sequential-mappings.patch KOSAKI Motohiro
2008-10-17 5:56 ` mm-more-likely-reclaim-madv_sequential-mappings.patch Nick Piggin
2008-10-17 16:51 ` mm-more-likely-reclaim-madv_sequential-mappings.patch Johannes Weiner
2008-10-18 1:30 ` mm-more-likely-reclaim-madv_sequential-mappings.patch Nick Piggin
2008-10-18 10:45 ` Johannes Weiner [this message]
2008-10-19 2:21 ` mm-more-likely-reclaim-madv_sequential-mappings.patch Nick Piggin
2008-10-19 2:43 ` mm-more-likely-reclaim-madv_sequential-mappings.patch Rik van Riel
2008-10-19 2:58 ` mm-more-likely-reclaim-madv_sequential-mappings.patch Nick Piggin
2008-10-19 14:39 ` mm-more-likely-reclaim-madv_sequential-mappings.patch Johannes Weiner
2008-10-21 1:45 ` mm-more-likely-reclaim-madv_sequential-mappings.patch Nick Piggin
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=87fxmu41wt.fsf@saeurebad.de \
--to=hannes@saeurebad.de \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
--cc=riel@redhat.com \
/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.