Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
From: Mel Gorman <hidden>
Date: 2005-11-04 01:48:15
Also in:
lkml
On Fri, 4 Nov 2005, Nick Piggin wrote:
Linus Torvalds wrote:quoted
On Fri, 4 Nov 2005, Nick Piggin wrote:quoted
Looks like ppc64 is getting 64K page support, at which point higher order allocations (eg. for stacks) basically disappear don't they?Yes and no, HOWEVER, nobody sane will ever use 64kB pages on a general-purpose machine. 64kB pages are _only_ usable for databases, nothing else. Why? Do the math. Try to cache the whole kernel source tree in 4kB pages vs 64kB pages. See how the memory usage goes up by a factor of _four_.Yeah that's true. But Martin's worried about future machines with massive memories - so maybe it is safe to assume those will be using big pages, I don't know.
Todays massive machines are tomorrows desktop. Weak comment, I know, but it's happened before.
Maybe the solution is to bloat the kernel sources enough to make 64KB pages worthwhile?
root@monocle:/boot# ls -l vmlinuz-2.6.14-rc5-mm1-clean -rw-r--r-- 1 root root 1718063 2005-11-01 16:17 vmlinuz-2.6.14-rc5-mm1-clean root@monocle:/boot# ls -l vmlinuz-2.6.14-rc5-mm1-mbuddy-v19 -rw-r--r-- 1 root root 1722102 2005-11-02 14:56 vmlinuz-2.6.14-rc5-mm1-mbuddy-v19 root@monocle:/boot# dc 1722102 1718063 - p 4039 root@monocle:/boot# ls -l vmlinux-2.6.14-rc5-mm1-clean -rwxr-xr-x 1 root root 31518866 2005-11-01 16:17 vmlinux-2.6.14-rc5-mm1-clean root@monocle:/boot# ls -l vmlinux-2.6.14-rc5-mm1-mbuddy-v19 -rwxr-xr-x 1 root root 31585714 2005-11-02 14:56 vmlinux-2.6.14-rc5-mm1-mbuddy-v19 mel@joshua:/usr/src/patchset-0.5/kernels/linux-2.6.14-rc5-mm1-nooom$ wc -l mm/page_alloc.c 2689 mm/page_alloc.c mel@joshua:/usr/src/patchset-0.5/kernels/linux-2.6.14-rc5-mm1-mbuddy-v19-withdefrag$ wc -l mm/page_alloc.c 3188 mm/page_alloc.c 0.23% increase in size of bzImage, 0.21% increase in the size of vmlinux and the major increase in code size is in one file, *one* file, all of which does it's best to impact the flow of the well-understood code. We're seeing bigger differences in performance than we are in the size of the kernel. I'd understand if I was the first person to ever introduce complexity to the VM. If the size of the image for really small systems is the issue, what if I say I'll add in another patch that optionally compiles away as much of anti-defrag as possible without making the code a mess of #defines . Are we still going to hear "no, I don't like looking at this". The current patch to compile it away deliberately choose the smallest part to take away to restore the allocator to todays behavior. -- Mel Gorman Part-time Phd Student Java Applications Developer 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>