Re: [PATCH 00 of 41] Transparent Hugepage Support #17

[Andrea Arcangeli <aarcange@redhat.com>]

On Mon, Apr 12, 2010 at 08:49:40AM +0200, Ingo Molnar wrote:
> AFAIK that's what Andrea has done as a test - but yes, i agree that 
> fragmentation is the main design worry.

Well, I didn't only run a kernel compile for a couple of minutes to
show how memory compaction + in-kernel set_recommended_min_free_kbytes
behaved on my system. I can't claim my numbers are conclusive as it
only run for 1 day and half but there was some real unmovable load on
it. Plus uptime isn't the only variable, if you use the kernel to
create an hypervisor product, you can leave it running VM for a much
longer time than 1 day, and it won't ever generate the amount of
unmovable load that I generated in one day and half I guess.

I built a ton of packages including gcc, bison (which in javac
triggered the anon-vma bug before I backed it out) quite some other
stuff that come as a regular update with a couple of emerge world like
kvirc and stuff like that. There was mutt on lkml and linux-mm maildir
with some hundred thousand inodes for the email, and a dozen kernel
builds and git checkouts to verify my aa.git tree. That's what I can
recall. After 1 day and half I still had ~80% of the not allocated ram
in order 9 and maybe ~75% (by memory, could have been more or less I
don't remember exactly but I posted the exact buddyinfo so you can
calculate yourself if curious) in order 10 == MAX_ORDER. The vast
majority of the free ram was in order 10 after echo 3 >drop_caches and
echo >compact_memory, which simulates the maximum ability of the VM to
generate hugepages dynamically (of course it won't ever create such a
totally compacted buddyinfo at runtime as we don't want to shrink or
compact stuff unless it's really needed). Likely if I killed mutt and
other running apps and I would have run drop_caches and memory
compaction again I would have gotten an even higher ratio as result of
more memory being freeable.

One day and half isn't enough, but it was initial data, and then I had
to reboot into a new #20 release to test a memleak fix I did in
do_huge_pmd_wp_page_fallback... I'll try to run it for a longer time
now. I guess I'll be rebuilding quite some glibc on my system as we
optimize it for the kernel.

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