[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84FF21A720B0874AA94B46D76DB9826904554B81@008-AM1MPN1-003.mgdnok.nokia.com>
Date: Mon, 9 Jan 2012 10:19:30 +0000
From: <leonid.moiseichuk@...ia.com>
To: <rientjes@...gle.com>
CC: <gregkh@...e.de>, <linux-mm@...ck.org>,
<linux-kernel@...r.kernel.org>, <cesarb@...arb.net>,
<kamezawa.hiroyu@...fujitsu.com>, <emunson@...bm.net>,
<penberg@...nel.org>, <aarcange@...hat.com>, <riel@...hat.com>,
<mel@....ul.ie>, <dima@...roid.com>, <rebecca@...roid.com>,
<san@...gle.com>, <akpm@...ux-foundation.org>,
<vesa.jaaskelainen@...ia.com>
Subject: RE: [PATCH 3.2.0-rc1 3/3] Used Memory Meter pseudo-device module
> -----Original Message-----
> From: ext David Rientjes [mailto:rientjes@...gle.com]
> Sent: 09 January, 2012 12:09
...
>
> I'm not sure why you need to detect low memory thresholds if you're not
> interested in using the memory controller, why not just use the oom killer
> delay that I suggested earlier and allow userspace to respond to conditions
> when you are known to failed reclaim and require that something be killed?
As I understand that is required to turn on memcg and memcg is a thing I try to avoid.
> > 1.7. David Rientjes
> > > This is just a side-note but as this information is meant to be
> > > consumed by userspace you have the option of hooking into the
> > > mm_page_alloc tracepoint. You get the same information about how
> > > many pages are allocated or freed. I accept that it will probably be a bit
> slower but on the plus side it'll be backwards compatible and you don't need
> a kernel patch for it.
> >
>
> I didn't write that.
Sorry, it was Mel Gorman. Copy-paste problem.
--
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