From: Mel Gorman <mgorman@suse.de>
To: Minchan Kim <minchan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Rik van Riel <riel@redhat.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH] mm: Warn about costly page allocation
Date: Mon, 9 Jul 2012 14:05:51 +0100 [thread overview]
Message-ID: <20120709130551.GA14154@suse.de> (raw)
In-Reply-To: <20120709125048.GA2203@barrios>
On Mon, Jul 09, 2012 at 09:50:48PM +0900, Minchan Kim wrote:
> > <SNIP>
> >
> > You're aiming this at embedded QA people according to your changelog so
> > do whatever you think is going to be the most effective. It's already
> > "known" that high-order kernel allocations are meant to be unreliable and
> > apparently this is being ignored. The in-code warning could look
> > something like
> >
> > if (unlikely(order > PAGE_ALLOC_COSTLY_ORDER)) {
> > printk_once("%s: page allocation high-order stupidity: order:%d, mode:0x%x\n",
> > current->comm, order, gfp_mask);
> > if (gfp_flags & __GFP_MOVABLE) {
> > printk_once("Enable compaction or whatever\n");
> > dump_stack();
> > } else {
> > printk_once("Regular high-order kernel allocations like this will eventually start failing.");
> > dump_stack();
> > }
> > }
>
> I'm not sure we have to check further for __GFP_MOVABLE because I have not seen driver
> uses __GFP_MOVABLE for high order allocation. Although it uses the flag, it's never
> compactable since it's out of LRU list. So I think it's rather overkill.
>
Then I would have considered it even more important to warn them that
their specific usage is going to break eventually, with or without
compaction. However, you know the target audience for this warning so it's
your call.
> >
> > There should be a comment above it giving more information if you think
> > the embedded people will actually read it. Of course, if this warning
> > triggers during driver initialisation then it might be a completely useless.
> > You could rate limit the warning (printk_ratelimit()) instead to be more
> > effective. As I don't know what sort of device drivers you are seeing this
> > problem with I can't judge what the best style of warning would be.
>
> Okay.
> I will send patch like below tomorrow if there isn't any objection.
>
> if (unlikely(order > PAGE_ALLOC_COSTLY_ORDER)) {
> if (printk_ratelimit()) {
> printk("%s: page allocation high-order stupidity: order:%d, mode:0x%x\n",
> current->comm, order, gfp_mask);
> printk_once("Enable compaction or whatever\n");
> printk_once("Regular high-order kernel allocations like this will eventually start failing.\n");
> dump_stack();
> }
> }
The warning message could be improved. I did not expect you to use "Enable
compaction or whatever" verbatim. I was just illustrating what type of
warnings I thought might be useful. I expected you would change it to
something that embedded driver authors would pay attention to :)
As you are using printk_ratelimit(), you can also use pr_warning to
annotate this as KERN_WARNING.
--
Mel Gorman
SUSE Labs
--
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>
next prev parent reply other threads:[~2012-07-09 13:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-09 2:38 [PATCH] mm: Warn about costly page allocation Minchan Kim
2012-07-09 8:22 ` Mel Gorman
2012-07-09 8:46 ` Minchan Kim
2012-07-09 9:12 ` Mel Gorman
2012-07-09 12:50 ` Minchan Kim
2012-07-09 13:05 ` Mel Gorman [this message]
2012-07-09 13:19 ` Minchan Kim
2012-07-09 20:53 ` Andrew Morton
2012-07-09 12:53 ` Cong Wang
2012-07-09 14:12 ` Minchan Kim
2012-07-11 2:45 ` Cong Wang
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=20120709130551.GA14154@suse.de \
--to=mgorman@suse.de \
--cc=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=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).