[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1201051458560.10521@chino.kir.corp.google.com>
Date: Thu, 5 Jan 2012 15:01:10 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Pekka Enberg <penberg@...nel.org>
cc: Rik van Riel <riel@...hat.com>, Greg KH <gregkh@...e.de>,
Leonid Moiseichuk <leonid.moiseichuk@...ia.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
cesarb@...arb.net, kamezawa.hiroyu@...fujitsu.com,
emunson@...bm.net, aarcange@...hat.com, mel@....ul.ie,
dima@...roid.com, rebecca@...roid.com, san@...gle.com,
akpm@...ux-foundation.org, vesa.jaaskelainen@...ia.com,
Minchan Kim <minchan@...hat.com>,
KOSAKI Motohiro <kosaki.motohiro@...il.com>
Subject: Re: [PATCH 3.2.0-rc1 0/3] Used Memory Meter pseudo-device and related
changes in MM
On Wed, 4 Jan 2012, Pekka Enberg wrote:
> And even if people want to support multiple ABIs and fight it out to
> see which one wins, we should factor out the generic parts and put
> them under mm/*.c and not hide them in random modules.
>
Agreed. This came up recently when another lowmem killer was proposed and
the suggestion was to enable the memory controller to be able to have the
memory threshold notifications with eventfd(2) and cgroup.event_control.
It would be very nice to have a generic lowmem notifier (like
/dev/mem_notify that has been reworked several times in the past) rather
than tying it to a particular cgroup, especially when that cgroup incurs a
substantial overhead for embedded users.
--
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