From: Andrea Arcangeli <aarcange@redhat.com>
To: Shaohua Li <shaohua.li@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm <linux-mm@kvack.org>,
"Chen, Tim C" <tim.c.chen@intel.com>, Mel Gorman <mel@csn.ul.ie>
Subject: Re: too big min_free_kbytes
Date: Mon, 24 Jan 2011 16:00:34 +0100 [thread overview]
Message-ID: <20110124150033.GB9506@random.random> (raw)
In-Reply-To: <1295841406.1949.953.camel@sli10-conroe>
eOn Mon, Jan 24, 2011 at 11:56:46AM +0800, Shaohua Li wrote:
> Hi,
> With transparent huge page, min_free_kbytes is set too big.
> Before:
> Node 0, zone DMA32
> pages free 1812
> min 1424
> low 1780
> high 2136
> scanned 0
> spanned 519168
> present 511496
>
> After:
> Node 0, zone DMA32
> pages free 482708
> min 11178
> low 13972
> high 16767
> scanned 0
> spanned 519168
> present 511496
> This caused different performance problems in our test. I wonder why we
> set the value so big.
It's to enable Mel's anti-frag that keeps pageblocks with movable and
unmovable stuff separated, same as "hugeadm
--set-recommended-min_free_kbytes".
Now that I checked, I'm seeing quite too much free memory with only 4G
of ram... You can see the difference with a "cp /dev/sda /dev/null" in
background interleaving these two commands:
echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo 1000 > /proc/sys/vm/min_free_kbytes
The setting of min_free_kbytes to 67584 leads to 716MB of memory
free. Setting to 1000 leads to 20MB free. I'm afraid losing 716MB on a
4G system is way excessive regardless of THP... can't we just have a
version of anti-frag that reserves a lot fewers pageblocks? Anti-frag
is quite important to avoid slab to fragment everything. I don't think
we can leave it like this.
For now you can workaround with the above echo 1000 > ...
--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-01-24 15:01 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-24 3:56 too big min_free_kbytes Shaohua Li
2011-01-24 15:00 ` Andrea Arcangeli [this message]
2011-01-25 14:35 ` Mel Gorman
2011-01-26 14:17 ` Mel Gorman
2011-01-26 15:23 ` Mel Gorman
2011-01-26 15:42 ` Andrea Arcangeli
2011-01-26 16:36 ` Mel Gorman
2011-01-26 17:42 ` Mel Gorman
2011-01-27 13:40 ` Mel Gorman
2011-01-27 15:27 ` Andrea Arcangeli
2011-01-27 16:03 ` Mel Gorman
2011-01-27 18:52 ` Andrea Arcangeli
2011-01-27 20:33 ` Rik van Riel
2011-01-27 21:31 ` Mel Gorman
2011-01-27 23:18 ` Rik van Riel
2011-01-28 10:35 ` Mel Gorman
2011-01-28 16:28 ` Andrea Arcangeli
2011-01-28 16:46 ` Mel Gorman
2011-01-28 17:16 ` Rik van Riel
2011-01-28 17:46 ` Andrea Arcangeli
2011-01-28 18:03 ` Rik van Riel
2011-01-28 18:24 ` Andrea Arcangeli
2011-01-28 19:34 ` Rik van Riel
2011-01-28 19:45 ` Andrea Arcangeli
2011-01-28 20:55 ` Rik van Riel
2011-01-29 19:45 ` Andrea Arcangeli
2011-01-28 17:34 ` Andrea Arcangeli
2011-01-28 17:10 ` Rik van Riel
2011-02-03 2:58 ` Andrea Arcangeli
2011-02-03 13:15 ` Mel Gorman
2011-02-03 18:59 ` Andrea Arcangeli
2011-02-03 14:36 ` Rik van Riel
2011-02-03 19:11 ` Andrea Arcangeli
2011-02-12 1:28 ` Simon Kirby
2011-02-14 2:25 ` Shaohua Li
2011-02-22 14:25 ` Mel Gorman
2011-02-22 14:42 ` Andrea Arcangeli
2011-02-22 14:50 ` Mel Gorman
2011-02-22 14:54 ` Andrea Arcangeli
2011-02-22 16:04 ` Mel Gorman
2011-02-22 16:40 ` Rik van Riel
2011-02-23 5:29 ` Shaohua Li
2011-02-23 14:45 ` Andrea Arcangeli
2011-02-24 8:08 ` Shaohua Li
2011-02-24 9:52 ` Mel Gorman
2011-02-24 9:57 ` Mel Gorman
2011-02-24 14:27 ` Andrea Arcangeli
2011-02-24 14:04 ` Andrea Arcangeli
2011-02-25 0:51 ` Shaohua Li
2011-02-25 12:13 ` Mel Gorman
2011-02-12 9:48 ` alex shi
2011-02-22 14:24 ` 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=20110124150033.GB9506@random.random \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=shaohua.li@intel.com \
--cc=tim.c.chen@intel.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.