All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Minchan Kim <minchan@kernel.org>,
	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 22:19:42 +0900	[thread overview]
Message-ID: <20120709131942.GA3594@barrios> (raw)
In-Reply-To: <20120709130551.GA14154@suse.de>

On Mon, Jul 09, 2012 at 02:05:51PM +0100, Mel Gorman wrote:
> 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");

s/printk_once/printk/g
Copy&Paste should go away. :(

> > 		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 :)

Okay.

> 
> As you are using printk_ratelimit(), you can also use pr_warning to
> annotate this as KERN_WARNING.

Will do.
Thanks, Mel.

> 
> -- 
> 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>

WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Minchan Kim <minchan@kernel.org>,
	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 22:19:42 +0900	[thread overview]
Message-ID: <20120709131942.GA3594@barrios> (raw)
In-Reply-To: <20120709130551.GA14154@suse.de>

On Mon, Jul 09, 2012 at 02:05:51PM +0100, Mel Gorman wrote:
> 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");

s/printk_once/printk/g
Copy&Paste should go away. :(

> > 		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 :)

Okay.

> 
> As you are using printk_ratelimit(), you can also use pr_warning to
> annotate this as KERN_WARNING.

Will do.
Thanks, Mel.

> 
> -- 
> Mel Gorman
> SUSE Labs

  reply	other threads:[~2012-07-09 13:19 UTC|newest]

Thread overview: 21+ 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  2:38 ` Minchan Kim
2012-07-09  8:22 ` Mel Gorman
2012-07-09  8:22   ` Mel Gorman
2012-07-09  8:46   ` Minchan Kim
2012-07-09  8:46     ` Minchan Kim
2012-07-09  9:12     ` Mel Gorman
2012-07-09  9:12       ` Mel Gorman
2012-07-09 12:50       ` Minchan Kim
2012-07-09 12:50         ` Minchan Kim
2012-07-09 13:05         ` Mel Gorman
2012-07-09 13:05           ` Mel Gorman
2012-07-09 13:19           ` Minchan Kim [this message]
2012-07-09 13:19             ` Minchan Kim
2012-07-09 20:53             ` Andrew Morton
2012-07-09 20:53               ` Andrew Morton
2012-07-09 12:53     ` Cong Wang
2012-07-09 14:12       ` Minchan Kim
2012-07-09 14:12         ` Minchan Kim
2012-07-11  2:45         ` Cong Wang
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=20120709131942.GA3594@barrios \
    --to=minchan@kernel.org \
    --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=mgorman@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.