From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: John Stultz <john.stultz@linaro.org>
Cc: LKML <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>,
Dave Hansen <dave@linux.vnet.ibm.com>,
Rik van Riel <riel@redhat.com>,
Dmitry Adamushko <dmitry.adamushko@gmail.com>,
Dave Chinner <david@fromorbit.com>, Neil Brown <neilb@suse.de>,
Andrea Righi <andrea@betterlinux.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Taras Glek <tgek@mozilla.com>, Mike Hommey <mh@glandium.org>,
Jan Kara <jack@suse.cz>,
kosaki.motohiro@gmail.com
Subject: Re: [PATCH 3/3] [RFC] tmpfs: Add FALLOC_FL_MARK_VOLATILE/UNMARK_VOLATILE handlers
Date: Fri, 01 Jun 2012 16:17:35 -0400 [thread overview]
Message-ID: <4FC9235F.5000402@gmail.com> (raw)
In-Reply-To: <1338575387-26972-4-git-send-email-john.stultz@linaro.org>
Hi John,
(6/1/12 2:29 PM), John Stultz wrote:
> This patch enables FALLOC_FL_MARK_VOLATILE/UNMARK_VOLATILE
> functionality for tmpfs making use of the volatile range
> management code.
>
> Conceptually, FALLOC_FL_MARK_VOLATILE is like a delayed
> FALLOC_FL_PUNCH_HOLE. This allows applications that have
> data caches that can be re-created to tell the kernel that
> some memory contains data that is useful in the future, but
> can be recreated if needed, so if the kernel needs, it can
> zap the memory without having to swap it out.
>
> In use, applications use FALLOC_FL_MARK_VOLATILE to mark
> page ranges as volatile when they are not in use. Then later
> if they wants to reuse the data, they use
> FALLOC_FL_UNMARK_VOLATILE, which will return an error if the
> data has been purged.
>
> This is very much influenced by the Android Ashmem interface by
> Robert Love so credits to him and the Android developers.
> In many cases the code& logic come directly from the ashmem patch.
> The intent of this patch is to allow for ashmem-like behavior, but
> embeds the idea a little deeper into the VM code.
>
> This is a reworked version of the fadvise volatile idea submitted
> earlier to the list. Thanks to Dave Chinner for suggesting to
> rework the idea in this fashion. Also thanks to Dmitry Adamushko
> for continued review and bug reporting, and Dave Hansen for
> help with the original design and mentoring me in the VM code.
I like this patch concept. This is cleaner than userland
notification quirk. But I don't like you use shrinker. Because of,
after applying this patch, normal page reclaim path can still make
swap out. this is undesirable.
(snip)
> +static
> +int shmem_volatile_shrink(struct shrinker *ignored, struct shrink_control *sc)
> +{
> + s64 nr_to_scan = sc->nr_to_scan;
> + const gfp_t gfp_mask = sc->gfp_mask;
> + struct address_space *mapping;
> + loff_t start, end;
> + int ret;
> + s64 page_count;
> +
> + if (nr_to_scan&& !(gfp_mask& __GFP_FS))
> + return -1;
> +
> + volatile_range_lock(&shmem_volatile_head);
> + page_count = volatile_range_lru_size(&shmem_volatile_head);
> + if (!nr_to_scan)
> + goto out;
> +
> + do {
> + ret = volatile_ranges_get_last_used(&shmem_volatile_head,
> + &mapping,&start,&end);
Why drop last used region? Not recently used region is better?
> + if (ret) {
> + shmem_truncate_range(mapping->host,
> + start<<PAGE_CACHE_SHIFT,
> + (end<<PAGE_CACHE_SHIFT)-1);
> + nr_to_scan -= end-start;
> + page_count -= end-start;
> + };
> + } while (ret&& (nr_to_scan> 0));
> +
> +out:
> + volatile_range_unlock(&shmem_volatile_head);
> +
> + return page_count;
> +}
> +
next prev parent reply other threads:[~2012-06-01 20:17 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-01 18:29 [PATCH 0/3] [RFC] Fallocate Volatile Ranges v2 John Stultz
2012-06-01 18:29 ` [PATCH 1/3] [RFC] Interval tree implementation John Stultz
2012-06-01 18:29 ` [PATCH 2/3] [RFC] Add volatile range management code John Stultz
2012-06-01 18:29 ` [PATCH 3/3] [RFC] tmpfs: Add FALLOC_FL_MARK_VOLATILE/UNMARK_VOLATILE handlers John Stultz
2012-06-01 20:17 ` KOSAKI Motohiro [this message]
2012-06-01 21:03 ` John Stultz
2012-06-01 21:37 ` KOSAKI Motohiro
2012-06-01 21:44 ` John Stultz
2012-06-01 22:34 ` KOSAKI Motohiro
2012-06-01 23:25 ` John Stultz
2012-06-06 19:52 ` KOSAKI Motohiro
2012-06-06 23:56 ` John Stultz
2012-06-07 10:55 ` Dmitry Adamushko
2012-06-07 23:41 ` Dave Hansen
2012-06-08 3:03 ` John Stultz
2012-06-08 4:50 ` KOSAKI Motohiro
2012-06-09 3:45 ` John Stultz
2012-06-10 6:35 ` Dmitry Adamushko
2012-06-10 21:47 ` Rik van Riel
2012-06-11 18:35 ` John Stultz
2012-06-12 1:21 ` John Stultz
2012-06-12 7:16 ` Minchan Kim
2012-06-12 7:16 ` Minchan Kim
2012-06-12 16:03 ` KOSAKI Motohiro
2012-06-12 16:03 ` KOSAKI Motohiro
2012-06-12 19:35 ` John Stultz
2012-06-12 19:35 ` John Stultz
2012-06-13 0:10 ` Minchan Kim
2012-06-13 0:10 ` Minchan Kim
2012-06-13 1:21 ` John Stultz
2012-06-13 1:21 ` John Stultz
2012-06-13 4:42 ` Minchan Kim
2012-06-13 4:42 ` Minchan Kim
2012-06-08 6:39 ` KOSAKI Motohiro
-- strict thread matches above, loose matches on Subject: below --
2012-06-01 23:38 [PATCH 0/3] [RFC] Fallocate Volatile Ranges v3 John Stultz
2012-06-01 23:38 ` [PATCH 3/3] [RFC] tmpfs: Add FALLOC_FL_MARK_VOLATILE/UNMARK_VOLATILE handlers 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=4FC9235F.5000402@gmail.com \
--to=kosaki.motohiro@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andrea@betterlinux.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=dave@linux.vnet.ibm.com \
--cc=david@fromorbit.com \
--cc=dmitry.adamushko@gmail.com \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=john.stultz@linaro.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=mh@glandium.org \
--cc=neilb@suse.de \
--cc=riel@redhat.com \
--cc=rlove@google.com \
--cc=tgek@mozilla.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.