From: Mel Gorman <mel@csn.ul.ie>
To: Iram Shahzad <iram.shahzad@jp.fujitsu.com>
Cc: linux-mm@kvack.org
Subject: Re: compaction: why depends on HUGETLB_PAGE
Date: Fri, 30 Jul 2010 10:57:40 +0100 [thread overview]
Message-ID: <20100730095740.GD3571@csn.ul.ie> (raw)
In-Reply-To: <545904F46F6C4026A234512CEAED30AE@rainbow>
On Fri, Jul 30, 2010 at 11:56:25AM +0900, Iram Shahzad wrote:
> Mel Gorman wrote:
>>> My question is: why does it depend on CONFIG_HUGETLB_PAGE?
>>
>> Because as the Kconfig says "Allows the compaction of memory for the
>> allocation of huge pages.". Depending on compaction to satisfy other
>> high-order allocation types is not likely to be a winning strategy.
>
> Please could you elaborate a little more why depending on
> compaction to satisfy other high-order allocation is not good.
>
At the very least, it's not a situation that has been tested heavily and
because other high-order allocations are typically not movable. In the
worst case, if they are both frequent and long-lived they *may* eventually
encounter fragmentation-related problems. This uncertainity is why it's
not good. It gets worse if there is no swap as eventually all movable pages
will be compacted as much as possible but there still might not be enough
contiguous memory for a high-order page because other pages are pinned.
>>> Is it wrong to use it on ARM by disabling CONFIG_HUGETLB_PAGE?
>>>
>>
>> It depends on why you need compaction. If it's for some device that
>> requires high-order allocations (particularly if they are atomic), then
>> it's not likely to work very well in the long term.
>
> Would you please elaborate on this as well.
>
In the case the allocation is atomic and there isn't a suitable page
available, compaction cannot occur either. Given enough uptime, there
will be failure reports as a result. Avoid high-order allocations where
possible.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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:[~2010-07-30 9:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-29 1:53 compaction: why depends on HUGETLB_PAGE Iram Shahzad
2010-07-29 12:57 ` Mel Gorman
2010-07-30 2:56 ` Iram Shahzad
2010-07-30 9:57 ` Mel Gorman [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-07-30 16:44 Round Robinjp
2010-07-30 16:49 ` Mel Gorman
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=20100730095740.GD3571@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=iram.shahzad@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
/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).