public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: Dmitry Adamushko <dmitry.adamushko@gmail.com>,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	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>, Rik van Riel <riel@redhat.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>
Subject: Re: [PATCH 3/3] [RFC] tmpfs: Add FALLOC_FL_MARK_VOLATILE/UNMARK_VOLATILE handlers
Date: Thu, 07 Jun 2012 20:03:10 -0700	[thread overview]
Message-ID: <4FD16B6E.8000307@linaro.org> (raw)
In-Reply-To: <4FD13C30.2030401@linux.vnet.ibm.com>

On 06/07/2012 04:41 PM, Dave Hansen wrote:
> On 06/07/2012 03:55 AM, Dmitry Adamushko wrote:
>> but maybe we should also purge them before we swap out some non-tmpfs
>> pages or drop some file-backed pages?
>
> Sure...  I guess we could kick that from either direct reclaim or from
> kswapd.  But, then we're basically back to the places where
> shrink_slab() is called.
>
> I think that means that we think it's preferable to integrate this more
> directly in the VM instead of sticking it off in the corner of tmpfs
> only, or pretending it's a slab.
>
> Dunno...  The slab shrinker one isn't looking _so_ bad at the moment.

Dave also pointed out to me on irc that on a system without swap, 
shmem_writepage doesn't even get called, which kills the utility of 
triggering volatile purging from writepage.

So I'm falling back to using a shrinker for now, but I think Dmitry's 
point is an interesting one, and am interested in finding a better place 
to trigger purging volatile ranges from the mm code. If anyone has any 
suggestions, let me know, otherwise I'll go back to trying to better 
grok the mm code.

thanks
-john



  reply	other threads:[~2012-06-08  3:03 UTC|newest]

Thread overview: 29+ 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
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 [this message]
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 16:03                               ` KOSAKI Motohiro
2012-06-12 19:35                               ` John Stultz
2012-06-13  0:10                                 ` Minchan Kim
2012-06-13  1:21                                   ` John Stultz
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=4FD16B6E.8000307@linaro.org \
    --to=john.stultz@linaro.org \
    --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=kernel-team@android.com \
    --cc=kosaki.motohiro@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox