linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Minchan Kim <minchan@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Rik van Riel <riel@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH v2] mm: Warn about costly page allocation
Date: Mon, 9 Jul 2012 17:08:56 -0700	[thread overview]
Message-ID: <20120709170856.ca67655a.akpm@linux-foundation.org> (raw)
In-Reply-To: <1341878153-10757-1-git-send-email-minchan@kernel.org>

On Tue, 10 Jul 2012 08:55:53 +0900
Minchan Kim <minchan@kernel.org> wrote:

> ...
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2276,6 +2276,29 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
>  	return alloc_flags;
>  }
>  
> +#if defined(CONFIG_DEBUG_VM) && !defined(CONFIG_COMPACTION)
> +static inline void check_page_alloc_costly_order(unsigned int order, gfp_t flags)
> +{
> +	if (likely(order <= PAGE_ALLOC_COSTLY_ORDER))
> +		return;
> +
> +	if (!printk_ratelimited())
> +		return;
> +
> +	pr_warn("%s: page allocation high-order stupidity: "
> +		"order:%d, mode:0x%x\n", current->comm, order, flags);
> +	pr_warn("Enable compaction if high-order allocations are "
> +		"very few and rare.\n");
> +	pr_warn("If you need regular high-order allocation, "
> +		"compaction wouldn't help it.\n");
> +	dump_stack();
> +}
> +#else
> +static inline void check_page_alloc_costly_order(unsigned int order)
> +{
> +}
> +#endif

Let's remember that plain old "inline" is ignored by the compiler.  If
we really really want to inline something then we should use
__always_inline.

And inlining this function would be a bad thing to do - it causes the
outer function to have an increased cache footprint.  A good way to
optimise this function is probably to move the unlikely stuff
out-of-line:

	if (unlikely(order > PAGE_ALLOC_COSTLY_ORDER))
		check_page_alloc_costly_order(...);

or

static noinline void __check_page_alloc_costly_order(...)
{
}

static __always_inline void check_page_alloc_costly_order(...)
{
	if (unlikely(order > PAGE_ALLOC_COSTLY_ORDER))
		__check_page_alloc_costly_order(...);
}
	

Also, the displayed messages don't seem very, umm, professional.  Who
was stupid - us or the kernel-configurer?  And "Enable
CONFIG_COMPACTION" would be more specific (and hence helpful) than
"Enable compaction").

And how on earth is the user, or the person who is configuring kernels
for customers to determine whether the kernel will be frequently
performing higher-order allocations?


So I dunno, this all looks like we have a kernel problem and we're
throwing our problem onto hopelessly ill-equipped users of that kernel?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2012-07-10  0:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-09 23:55 [PATCH v2] mm: Warn about costly page allocation Minchan Kim
2012-07-10  0:03 ` Minchan Kim
2012-07-10  0:08 ` Andrew Morton [this message]
2012-07-10  0:25   ` Minchan Kim
2012-07-11  1:02     ` David Rientjes
2012-07-11  2:23       ` Minchan Kim
2012-07-11  2:50         ` Cong Wang
2012-07-11  5:33         ` David Rientjes
2012-07-11  5:57           ` Minchan Kim
2012-07-11 20:40             ` David Rientjes
2012-07-11 21:18               ` Minchan Kim
2012-07-11 23:02                 ` David Rientjes
2012-07-11 23:55                   ` Minchan Kim
2012-07-12  2:33                     ` David Rientjes
2012-07-12  3:00                       ` Minchan Kim
  -- strict thread matches above, loose matches on Subject: below --
2012-07-10  1:02 Minchan Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120709170856.ca67655a.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=minchan@kernel.org \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).