Re: [PATCH 3.2.0-rc1 2/3] MM hook for page allocation and release

From: Mel Gorman
Date: Thu Jan 05 2012 - 10:22:55 EST


On Wed, Jan 04, 2012 at 07:21:55PM +0200, Leonid Moiseichuk wrote:
> That is required by Used Memory Meter (UMM) pseudo-device
> to track memory utilization in system. It is expected that
> hook MUST be very light to prevent performance impact
> on the hot allocation path. Accuracy of number managed pages
> does not expected to be absolute but fact of allocation or
> deallocation must be registered.
>
> Signed-off-by: Leonid Moiseichuk <leonid.moiseichuk@xxxxxxxxx>
> ---
> include/linux/mm.h | 15 +++++++++++++++
> mm/Kconfig | 8 ++++++++
> mm/page_alloc.c | 31 +++++++++++++++++++++++++++++++
> 3 files changed, 54 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 3dc3a8c..d133f73 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1618,6 +1618,21 @@ extern int soft_offline_page(struct page *page, int flags);
>
> extern void dump_page(struct page *page);
>
> +#ifdef CONFIG_MM_ALLOC_FREE_HOOK
> +/*
> + * Hook function type which called when some pages allocated or released.
> + * Value of nr_pages is positive for post-allocation calls and negative
> + * after free.
> + */
> +typedef void (*mm_alloc_free_hook_t)(int nr_pages);
> +
> +/*

I'm going to chime in and say that hooks like this into the page
allocator are a no-go unless there really is absolutely no other option.
There is too much scope for abuse.

Even if they were not, this takes no account of the zone or node
we are allocating from making it useful only in the case where the
system had a single node and zone. This applies to mobile devices
but not a lot of other systems.

It also would have very poor information about memory pressure which
is likely to be far more interesting and for that, awareness of what
is happening in page reclaim is required.

I haven't looked at the alternatives but there has been some vague
discussion recently on reviving the concept of a low memory notifier,
somehow making the existing memcg oom notifier global or maybe the
andro lowmem killer can be adapted to your needs.

> @@ -2298,6 +2322,10 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
> put_mems_allowed();
>
> trace_mm_page_alloc(page, order, gfp_mask, migratetype);
> +#ifdef CONFIG_MM_ALLOC_FREE_HOOK
> + call_alloc_free_hook(1 << order);
> +#endif
> +
> return page;
> }

you are calling a free hook there in the alloc path. Seems odd.

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.

--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/