lkml.org 
[lkml]   [2011]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2011-11-26 01:09    [W:0.198 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site