All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 17 Oct 2008 18:51:10 +0200	[thread overview]
Message-ID: <87k5c74135.fsf@saeurebad.de> (raw)
In-Reply-To: <200810171321.40725.nickpiggin@yahoo.com.au> (Nick Piggin's message of "Fri, 17 Oct 2008 13:21:40 +1100")

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?

	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>

  parent reply	other threads:[~2008-10-17 16:51 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       ` Johannes Weiner [this message]
2008-10-18  1:30         ` mm-more-likely-reclaim-madv_sequential-mappings.patch Nick Piggin
2008-10-18 10:45           ` mm-more-likely-reclaim-madv_sequential-mappings.patch Johannes Weiner
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=87k5c74135.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.