From: Dave Hansen <dave@linux.vnet.ibm.com>
To: NeilBrown <neilb@suse.de>
Cc: John Stultz <john.stultz@linaro.org>,
Dave Chinner <david@fromorbit.com>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Android Kernel Team <kernel-team@android.com>,
Robert Love <rlove@google.com>, Mel Gorman <mel@csn.ul.ie>,
Hugh Dickins <hughd@google.com>, Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 2/2] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and _NONVOLATILE flags
Date: Mon, 20 Feb 2012 15:25:33 -0800 [thread overview]
Message-ID: <4F42D66D.8090604@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120220183440.01bd4c5c@notabene.brown>
On 02/19/2012 11:34 PM, NeilBrown wrote:
> Is this a problem? If the typical granularity is a page or two then it is
> unlikely to hurt. If it is hundreds of pages I think it would mean that we
> don't make as good use of memory as we could (but it is all heuristics anyway
> and we probably waste lots of opportunities already so maybe it doesn't
> matter).
>
> My gut feeling is that seeing the app has concrete knowledge about
> granularity it should give it to the kernel somehow.
I dunno... The kernel works well with an awful lot of applications
without ever having any concept of the underlying objects.
I guess the worst-case scenario would be if we have a very large object,
most of its pages being accessed very often, but one never accessed.
The one page makes its way to the end of the LRU and gets discarded, now
the whole object is worthless, and most of it is at the beginning of the
LRU. If it is truly accessed often, then userspace should notice
quickly and discard the entire object quickly. If it isn't accessed
often, then the majority of the object is moving down the LRU and won't
be wasted for long.
What else can we do? I guess whenever a range is set NONVOLATILE, we
could SetPageReferenced() on every page in the range to keep them
bunched up on the LRU.
next prev parent reply other threads:[~2012-02-20 23:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-10 0:16 [PATCH 1/2] [RFC] Range tree implementation John Stultz
2012-02-10 0:16 ` [PATCH 2/2] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and _NONVOLATILE flags John Stultz
2012-02-12 14:08 ` Dmitry Adamushko
2012-02-17 3:49 ` John Stultz
2012-02-14 5:16 ` Dave Chinner
2012-02-14 5:55 ` John Stultz
2012-02-14 23:51 ` Dave Chinner
2012-02-15 0:29 ` John Stultz
2012-02-15 1:37 ` NeilBrown
2012-02-17 4:45 ` Dave Chinner
2012-02-17 5:27 ` NeilBrown
2012-02-17 5:38 ` John Stultz
2012-02-17 5:21 ` John Stultz
2012-02-20 7:34 ` NeilBrown
2012-02-20 23:25 ` Dave Hansen [this message]
[not found] ` <CAO6Zf6B6nGqsz5zpT3ixbO-+JWxMsScABasnwo-CVHuMKPqpLQ@mail.gmail.com>
2012-02-12 12:54 ` Fwd: " Dmitry Adamushko
2012-02-17 3:43 ` John Stultz
2012-02-17 5:24 ` John Stultz
-- strict thread matches above, loose matches on Subject: below --
2012-03-16 22:51 [PATCH 0/2] [RFC] Volatile ranges (v4) John Stultz
2012-03-16 22:51 ` [PATCH 2/2] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and _NONVOLATILE flags John Stultz
2012-03-17 16:21 ` Dmitry Adamushko
2012-03-18 9:13 ` Dmitry Adamushko
2012-03-20 0:18 ` John Stultz
2012-03-21 4:15 [PATCH 0/2] [RFC] fadivse volatile & range tree (v5) John Stultz
2012-03-21 4:15 ` [PATCH 2/2] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and _NONVOLATILE flags John Stultz
2012-04-07 0:08 [PATCH 0/2] [RFC] Volatile Ranges (v6) John Stultz
2012-04-07 0:08 ` [PATCH 2/2] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and _NONVOLATILE flags John Stultz
2012-04-14 1:07 [PATCH 0/2][RFC] Volatile Ranges (v7) John Stultz
2012-04-14 1:08 ` [PATCH 2/2] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and _NONVOLATILE flags John Stultz
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=4F42D66D.8090604@linux.vnet.ibm.com \
--to=dave@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hughd@google.com \
--cc=john.stultz@linaro.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=neilb@suse.de \
--cc=riel@redhat.com \
--cc=rlove@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;
as well as URLs for NNTP newsgroup(s).