[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20111126000521.GA26326@quack.suse.cz>
Date: Sat, 26 Nov 2011 01:05:21 +0100
From: Jan Kara <jack@...e.cz>
To: Rik van Riel <riel@...hat.com>
Cc: John Stultz <john.stultz@...aro.org>,
LKML <linux-kernel@...r.kernel.org>,
Robert Love <rlove@...gle.com>,
Christoph Hellwig <hch@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Hugh Dickins <hughd@...gle.com>, Mel Gorman <mel@....ul.ie>,
Dave Hansen <dave@...ux.vnet.ibm.com>,
Eric Anholt <eric@...olt.net>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Johannes Weiner <jweiner@...hat.com>,
Jon Masters <jcm@...hat.com>
Subject: Re: [PATCH] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and
_NONVOLATILE flags
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists