[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1326811093.3467.41.camel@lenny>
Date: Tue, 17 Jan 2012 09:38:10 -0500
From: Colin Walters <walters@...bum.org>
To: Minchan Kim <minchan@...nel.org>
Cc: linux-mm <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>,
leonid.moiseichuk@...ia.com, kamezawa.hiroyu@...fujitsu.com,
penberg@...nel.org, Rik van Riel <riel@...hat.com>, mel@....ul.ie,
rientjes@...gle.com, KOSAKI Motohiro <kosaki.motohiro@...il.com>,
Johannes Weiner <hannes@...xchg.org>,
Marcelo Tosatti <mtosatti@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Ronen Hod <rhod@...hat.com>
Subject: Re: [RFC 0/3] low memory notify
On Tue, 2012-01-17 at 17:13 +0900, Minchan Kim wrote:
> As you can see, it's respin of mem_notify core of KOSAKI and Marcelo.
> (Of course, KOSAKI's original patchset includes more logics but I didn't
> include all things intentionally because I want to start from beginning
> again) Recently, there are some requirements of notification of system
> memory pressure.
How does this relate to the existing cgroups memory notifications? See
Documentation/cgroups/memory.txt under "10. OOM Control"
> It would be very useful for various cases.
> For example, QEMU/JVM/Firefox like big memory hogger can release their memory
> when memory pressure happens.
I don't know about QEMU, but the key characteristic of the JVM and
Firefox is that they use garbage collection. Which also applies to
Python, Ruby, Google Go, Haskell, OCaml...
So what you really want to be investigating here is integration between
a garbage collector and the system VM. Your test program looks nothing
like a garbage collector. I'd expect most of the performance tradeoffs
to be similar between these runtimes. The Azul people have been doing
something like this: http://www.managedruntime.org/
In Firefox' case though it can also drop other caches, e.g.:
http://people.gnome.org/~federico/news-2007-09.html#firefox-memory-1
As far as the desktop goes, I want to get notified if we're going to hit
swap, not if we're close to exhausting the total of RAM+swap. While
swap may make sense for servers that care about throughput mainly, I
care a lot about latency.
--
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