From: David Rientjes <rientjes@google.com>
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>,
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: Wed, 11 Jul 2012 19:33:41 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.00.1207111930020.9370@chino.kir.corp.google.com> (raw)
In-Reply-To: <20120711235504.GA5204@bbox>
On Thu, 12 Jul 2012, Minchan Kim wrote:
> Agreed and that's why I suggested following patch.
> It's not elegant but at least, it could attract interest of configuration
> people and they could find a regression during test phase.
> This description could be improved later by writing new documenation which
> includes more detailed story and method for capturing high order allocation
> by ftrace once we see regression report.
>
> At the moment, I would like to post this patch, simply.
> (Of course, I hope fluent native people will correct a sentence. :) )
>
> Any objections, Andrew, David?
>
There are other config options like CONFIG_SLOB that are used for a very
small memory footprint on systems like this. We used to have
CONFIG_EMBEDDED to suggest options like this but that has since been
renamed as CONFIG_EXPERT and has become obscured.
If size is really the only difference, I would think that people who want
the smallest kernel possible would be doing allnoconfig and then
selectively enabling what they need, so defconfig isn't really relevant
here. And it's very difficult for an admin to know whether or not they
"care about high-order allocations."
I'd reconsider disabling compaction by default unless there are other
considerations that haven't been mentioned.
WARNING: multiple messages have this Message-ID (diff)
From: David Rientjes <rientjes@google.com>
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>,
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: Wed, 11 Jul 2012 19:33:41 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.00.1207111930020.9370@chino.kir.corp.google.com> (raw)
In-Reply-To: <20120711235504.GA5204@bbox>
On Thu, 12 Jul 2012, Minchan Kim wrote:
> Agreed and that's why I suggested following patch.
> It's not elegant but at least, it could attract interest of configuration
> people and they could find a regression during test phase.
> This description could be improved later by writing new documenation which
> includes more detailed story and method for capturing high order allocation
> by ftrace once we see regression report.
>
> At the moment, I would like to post this patch, simply.
> (Of course, I hope fluent native people will correct a sentence. :) )
>
> Any objections, Andrew, David?
>
There are other config options like CONFIG_SLOB that are used for a very
small memory footprint on systems like this. We used to have
CONFIG_EMBEDDED to suggest options like this but that has since been
renamed as CONFIG_EXPERT and has become obscured.
If size is really the only difference, I would think that people who want
the smallest kernel possible would be doing allnoconfig and then
selectively enabling what they need, so defconfig isn't really relevant
here. And it's very difficult for an admin to know whether or not they
"care about high-order allocations."
I'd reconsider disabling compaction by default unless there are other
considerations that haven't been mentioned.
--
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-12 2:33 UTC|newest]
Thread overview: 31+ 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-09 23:55 ` Minchan Kim
2012-07-10 0:03 ` Minchan Kim
2012-07-10 0:03 ` Minchan Kim
2012-07-10 0:08 ` Andrew Morton
2012-07-10 0:08 ` Andrew Morton
2012-07-10 0:25 ` Minchan Kim
2012-07-10 0:25 ` Minchan Kim
2012-07-11 1:02 ` David Rientjes
2012-07-11 1:02 ` David Rientjes
2012-07-11 2:23 ` Minchan Kim
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:33 ` David Rientjes
2012-07-11 5:57 ` Minchan Kim
2012-07-11 5:57 ` Minchan Kim
2012-07-11 20:40 ` David Rientjes
2012-07-11 20:40 ` David Rientjes
2012-07-11 21:18 ` Minchan Kim
2012-07-11 21:18 ` Minchan Kim
2012-07-11 23:02 ` David Rientjes
2012-07-11 23:02 ` David Rientjes
2012-07-11 23:55 ` Minchan Kim
2012-07-11 23:55 ` Minchan Kim
2012-07-12 2:33 ` David Rientjes [this message]
2012-07-12 2:33 ` David Rientjes
2012-07-12 3:00 ` Minchan Kim
2012-07-12 3:00 ` Minchan Kim
2012-07-10 1:02 Minchan Kim
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=alpine.DEB.2.00.1207111930020.9370@chino.kir.corp.google.com \
--to=rientjes@google.com \
--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=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 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.