linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Minchan Kim <minchan.kim@gmail.com>
To: Rik van Riel <riel@redhat.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Ken Chen <kenchen@google.com>, Ying Han <yinghan@google.com>,
	Hugh Dickins <hughd@google.com>, Nick Piggin <npiggin@gmail.com>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] mm: don't flush TLB when propagate PTE access bit to struct page.
Date: Fri, 29 Oct 2010 13:27:15 +0900	[thread overview]
Message-ID: <AANLkTiku321ZpSrO4hSLyj7n9NM7QvN+RQ-A73KK4eRa@mail.gmail.com> (raw)
In-Reply-To: <4CCA42D0.5090603@redhat.com>

On Fri, Oct 29, 2010 at 12:43 PM, Rik van Riel <riel@redhat.com> wrote:
> On 10/28/2010 10:45 PM, KAMEZAWA Hiroyuki wrote:
>
>> Hmm. Without flushing anywhere in memory reclaim path, a process which
>> cause page fault and enter vmscan will not see his own recent access bit
>> on
>> pages in LRU ?
>
> Worse still, because kernel threads do a lazy mmu switch, even
> page faulting in the process will not cause the TLB entries to
> be flushed.
>
>> I think it should be flushed at least once..
>
> A periodic flush may make sense.
>
> Maybe something along the lines of if the TLB has not been
> flushed for over a second (we can see that in timer or scheduler
> code), flush it?

What happens if we don't flush TLB?
It will make for old page to pretend young page.
If it is, how does it affect reclaim?

It makes for old page to promote into active list by page_check_references.
Of couse, It's not good. But for it, we have to keep wrong TLB until
moving head to tail in inactive list. It's very unlikely. That's
because TLB is very smalll and the process will be switching out.

If lumpy happens(ie, not waiting from head to tail in inactive list to
hold a victim page), that's all right since we ignore young bit in
lumpy case.

I think it's no problem unless inactive list is very short.
Remained one is kernel thread's lazy TLB flush.

So how about flushing TLB in kswapd scheduled in?


> --
> All rights reversed
>



-- 
Kind regards,
Minchan Kim

--
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>

  reply	other threads:[~2010-10-29  4:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-27 17:21 Ying Han
2010-10-27 18:05 ` Rik van Riel
2010-10-27 18:22   ` Nick Piggin
2010-10-27 18:37     ` Nick Piggin
2010-10-27 19:13       ` Hugh Dickins
2010-10-27 20:35         ` Ying Han
2010-10-28  0:11           ` KAMEZAWA Hiroyuki
2010-10-29  1:30             ` Ken Chen
2010-10-29  2:45               ` KAMEZAWA Hiroyuki
2010-10-29  3:43                 ` Rik van Riel
2010-10-29  4:27                   ` Minchan Kim [this message]
2010-10-29 12:31                     ` Rik van Riel
2010-10-29 13:03                       ` Minchan Kim
2010-10-29 13:15                         ` Rik van Riel
2010-10-30  0:20                           ` Minchan Kim
2010-10-27 20:19   ` Ying Han
2010-10-28 11:53     ` Rik van Riel

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=AANLkTiku321ZpSrO4hSLyj7n9NM7QvN+RQ-A73KK4eRa@mail.gmail.com \
    --to=minchan.kim@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kenchen@google.com \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@gmail.com \
    --cc=riel@redhat.com \
    --cc=yinghan@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox