[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOJsxLF706VeThxqWostJr84N_8q8UXoQzxGmMXj8mpgTLCagg@mail.gmail.com>
Date: Thu, 5 Jan 2012 14:49:42 +0200
From: Pekka Enberg <penberg@...nel.org>
To: leonid.moiseichuk@...ia.com
Cc: kamezawa.hiroyu@...fujitsu.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, cesarb@...arb.net, emunson@...bm.net,
aarcange@...hat.com, riel@...hat.com, mel@....ul.ie,
rientjes@...gle.com, dima@...roid.com, gregkh@...e.de,
rebecca@...roid.com, san@...gle.com, akpm@...ux-foundation.org,
vesa.jaaskelainen@...ia.com
Subject: Re: [PATCH 3.2.0-rc1 2/3] MM hook for page allocation and release
On Thu, Jan 5, 2012 at 1:26 PM, <leonid.moiseichuk@...ia.com> wrote:
> I agree that hooking alloc_pages is ugly way. So alternatives I see:
>
> - shrinkers (as e.g. Android OOM used) but shrink_slab called only from
> try_to_free_pages only if we are on slow reclaim path on memory allocation,
> so it cannot be used for e.g. 75% memory tracking or when pages released to
> notify user space that we are OK. But according to easy to use it will be the
> best approach.
>
> - memcg-kind of changes like mem_cgroup_newpage_charge/uncharge_page but
> without blocking decision making logic. Seems to me more changes. Threshold
> currently in memcg set 128 pages per CPU, that is quite often for level
> tracking needs.
>
> - tracking situation using timer? Maybe not due to will impact battery.
Can we hook into mm/vmscan.c and mm/page-writeback.c for this?
Pekka
--
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