Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

["Martin J. Bligh" <mbligh@mbligh.org>]

>> Ha. Just because I don't think I made you puke hard enough already with
>> foul approximations ... for order 2, I think it's
> 
> Your basic fault is in believing that the free watermark would stay 
> constant.
> 
> That's insane.
> 
> Would you keep 8MB free on a 64MB system?
> 
> Would you keep 8MB free on a 8GB system?
> 
> The point being, that if you start with insane assumptions, you'll get 
> insane answers.

Ummm. I was basing it on what we actually do now in the code, unless I
misread it, which is perfectly possible. Do you want this patch?

diff -purN -X /home/mbligh/.diff.exclude linux-2.6.14/mm/page_alloc.c 2.6.14-no_water_cap/mm/page_alloc.c
--- linux-2.6.14/mm/page_alloc.c	2005-10-27 18:52:20.000000000 -0700
+++ 2.6.14-no_water_cap/mm/page_alloc.c	2005-11-03 14:36:06.000000000 -0800
@@ -2387,8 +2387,6 @@ static void setup_per_zone_pages_min(voi
 			min_pages = zone->present_pages / 1024;
 			if (min_pages < SWAP_CLUSTER_MAX)
 				min_pages = SWAP_CLUSTER_MAX;
-			if (min_pages > 128)
-				min_pages = 128;
 			zone->pages_min = min_pages;
 		} else {
 			/* if it's a lowmem zone, reserve a number of pages


> The _correct_ assumption is that you aim to keep some fixed percentage of 
> memory free. With that assumption and your math, finding higher-order 
> pages is equally hard regardless of amount of memory. 

That would, indeed, make more sense.
 
> Now, your math then doesn't allow for the fact that buddy automatically 
> coalesces for you, so in fact things get _easier_ with more memory, but 
> hey, that needs more math than I can come up with (I never did it as math, 
> only as simulations with allocation patterns - "smart people use math, 
> plodding people just try to simulate an estimate" ;)

Not sure what people who do math, but wrongly, are called, but I'm sure 
it's not polite, and I'm sure I'm one of those ;-)

M.