linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Rik van Riel <riel@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Nick Piggin <npiggin@kernel.dk>, Mel Gorman <mel@csn.ul.ie>
Subject: Re: [RFC 1/2] deactive invalidated pages
Date: Mon, 22 Nov 2010 23:15:58 -0800	[thread overview]
Message-ID: <20101122231558.57b6e04c.akpm@linux-foundation.org> (raw)
In-Reply-To: <AANLkTimpfZuKW-hXjXknn3ESKP81AN3BaXO=qG81Lrae@mail.gmail.com>

On Tue, 23 Nov 2010 15:05:39 +0900 Minchan Kim <minchan.kim@gmail.com> wrote:

> On Tue, Nov 23, 2010 at 2:48 PM, Andrew Morton
> >> > move it to the head of the LRU anyway. __But given that the user has
> >>
> >> Why does it move into head of LRU?
> >> If the page which isn't mapped doesn't have PG_referenced, it would be
> >> reclaimed.
> >
> > If it's dirty or under writeback it can't be reclaimed!
> 
> I see your point. And it's why I add it to head of inactive list.

But that *guarantees* that the page will get a full trip around the
inactive list.  And this will guarantee that potentially useful pages
are reclaimed before the pages which we *know* the user doesn't want! 
Bad!

Whereas if we queue it to the tail, it will only get that full trip if
reclaim happens to run before the page is cleaned.  And we just agreed
that reclaim isn't likely to run immediately, because pages are being
freed.

So we face a choice between guaranteed eviction of potentially-useful
pages (which are very expensive to reestablish) versus a *possible*
need to move an unreclaimable page to the head of the LRU, which is
cheap.

So we need to decide if

	(certain * possibly-expensive) is less than (possible * cheap).

So no, it's not obvious to me that this was the correct decision.


One way to help with this guess would be to instrument those pages
(would require adding a special page flag to identify them, I expect)
and see how many of these pages get immediately reclaimed off the LRU
versus how many get recycled.  And then run a batch of "typical
workloads" under that instrumentation.

Only there aren't any "typical workloads" for fadvise(DONTNEED) :(

--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-11-23  7:28 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-21 14:30 Minchan Kim
2010-11-21 14:30 ` [RFC 2/2] Prevent promotion of page in madvise_dontneed Minchan Kim
2010-11-21 14:38   ` Minchan Kim
2010-11-21 16:34   ` Ben Gamari
2010-11-22  0:31     ` Minchan Kim
2010-11-22 22:21   ` Andrew Morton
2010-11-23  4:57     ` Minchan Kim
2010-11-23  9:50     ` Mel Gorman
2010-11-23 23:49       ` Minchan Kim
2010-11-21 15:21 ` [RFC 1/2] deactive invalidated pages Ben Gamari
2010-11-23  7:16   ` KOSAKI Motohiro
2010-11-23 13:48     ` Ben Gamari
2010-11-23 23:48       ` Minchan Kim
2010-11-23 14:49     ` [RFC PATCH] fadvise support in rsync Ben Gamari
2010-11-23 15:35       ` Pádraig Brady
2010-11-24  0:17       ` KOSAKI Motohiro
2010-11-23 14:49     ` [PATCH 1/3] Add fadvise interface wrapper Ben Gamari
2010-11-23 14:49     ` [PATCH 2/3] Inform kernel of FADV_DONTNEED hint in sender Ben Gamari
2010-11-23 14:49     ` [PATCH 3/3] Inform kernel of FADV_DONTNEED hint in receiver Ben Gamari
2010-11-22  1:17 ` [RFC 1/2] deactive invalidated pages Rik van Riel
2010-11-22 22:14 ` Andrew Morton
2010-11-23  4:52   ` Minchan Kim
2010-11-23  5:01     ` Andrew Morton
2010-11-23  5:23       ` Minchan Kim
2010-11-23  5:22         ` Andrew Morton
2010-11-23  5:45           ` Minchan Kim
2010-11-23  5:48             ` Andrew Morton
2010-11-23  6:05               ` Minchan Kim
2010-11-23  7:15                 ` Andrew Morton [this message]
2010-11-23  7:44                   ` Minchan Kim
2010-11-23  7:53                     ` Andrew Morton
2010-11-23  8:02                       ` Minchan Kim
2010-11-23  9:43               ` Mel Gorman
2010-11-23 23:32                 ` Minchan Kim
2010-11-23  9:38       ` Mel Gorman
2010-11-23 14:55         ` Ben Gamari
2010-11-23 14:58           ` Mel Gorman
2010-11-23 20:35             ` Andrew Morton
2010-11-23 22:10               ` Mel Gorman
2010-11-23 23:45                 ` Minchan Kim
2010-11-24 18:01                   ` Mel Gorman
2010-11-23  7:16 ` KOSAKI Motohiro
2010-11-23  7:40   ` Minchan Kim
2010-11-23  7:42     ` Andrew Morton
2010-11-23  8:01     ` KOSAKI Motohiro
2010-11-23  8:44       ` Minchan Kim
2010-11-23  9:02         ` KOSAKI Motohiro
2010-11-23  9:05           ` Minchan Kim
2010-11-23  9:07             ` Minchan Kim
2010-11-23 14:57   ` Ben Gamari
2010-11-24  0:13     ` KOSAKI Motohiro
2010-11-23  9:28 ` Mel Gorman
2010-11-23 23:24   ` Minchan Kim
2010-11-24 10:02     ` Mel Gorman

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=20101122231558.57b6e04c.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=minchan.kim@gmail.com \
    --cc=npiggin@kernel.dk \
    --cc=peterz@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox