mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Rik van Riel <riel@redhat.com>
Cc: John Stultz <john.stultz@linaro.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Robert Love <rlove@google.com>,
	Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>, Mel Gorman <mel@csn.ul.ie>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Eric Anholt <eric@anholt.net>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	Johannes Weiner <jweiner@redhat.com>,
	Jon Masters <jcm@redhat.com>
Subject: Re: [PATCH] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and _NONVOLATILE flags
Date: Sat, 26 Nov 2011 01:05:21 +0100	[thread overview]
Message-ID: <20111126000521.GA26326@quack.suse.cz> (raw)
In-Reply-To: <4ECB6D60.1010702@redhat.com>

On Tue 22-11-11 04:37:36, Rik van Riel wrote:
> On 11/21/2011 10:33 PM, John Stultz wrote:
> The idea is quite simple:
> 
> 1) Every program that we are interested in already has
>    some kind of main loop where it polls on file descriptors.
>    It is easy for such programs to add an additional file,
>    which would be a device or sysfs file that wakes up the
>    program from its poll/select loop when memory is getting
>    full to the point that userspace needs to shrink its
>    caches.
> 
>    The kernel can be smart here and wake up just one process
>    at a time, targeting specific NUMA nodes or cgroups. Such
>    kernel smarts do not require additional userspace changes.
> 
> 2) When userspace gets such a "please shrink your caches"
>    event, it can do various things.  A program like firefox
>    could throw away several cached objects, eg. uncompressed
>    images or entire pre-rendered tabs, while a JVM can shrink
>    its heap size and a database could shrink its internal
>    cache.
  Hmm, I wonder here: How much should a program free? A single object? Or
one meg of memory? I find this decision rather problematic. How much should
be reclaimed depends on the number of applications listening, how aggressive
they are, and current memory pressure => it's basically unpredictable from
userspace so you are almost guaranteed to either reclaim too much or too
few. Advantage of the VOLATILE approach is that kernel (which is the only
place where there is all necessary information) controls how much memory
is evicted... Just one argument for VOLATILE approach I didn't see
mentioned in the discussion yet.

								Honza

  parent reply	other threads:[~2011-11-26  0:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-22  3:33 John Stultz
2011-11-22  9:37 ` Rik van Riel
2011-11-22 10:45   ` Rik van Riel
2011-11-22 20:39     ` Dave Hansen
2011-11-22 16:31   ` Robert Love
2011-11-22 19:48   ` John Stultz
2011-11-23  0:27     ` Rik van Riel
     [not found]   ` <CAG6tG3xTkW1J=6xmUmmJoswJyR6ii5RDXvAsYrcH0CkVuUmJrQ@mail.gmail.com>
2011-11-23  0:39     ` Rik van Riel
2011-11-23 15:52       ` Robert Love
2011-11-26  0:05   ` Jan Kara [this message]
2011-11-22 20:52 ` Andrew Morton
2011-11-22 21:32   ` John Stultz
2011-11-22 21:39     ` Andrew Morton
2011-11-22 22:58       ` 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=20111126000521.GA26326@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=dave@linux.vnet.ibm.com \
    --cc=eric@anholt.net \
    --cc=hch@infradead.org \
    --cc=hughd@google.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jcm@redhat.com \
    --cc=john.stultz@linaro.org \
    --cc=jweiner@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --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

all inboxes | Powered by JetHome®