>> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Linus Torvalds <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- References:
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Ingo Molnar <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Dave Hansen <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Ingo Molnar <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Dave Hansen <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Ingo Molnar <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Dave Hansen <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Dave Hansen <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Nick Piggin <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: "Martin J. Bligh" <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Nick Piggin <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: "Martin J. Bligh" <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Arjan van de Ven <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Linus Torvalds <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Mel Gorman <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Linus Torvalds <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: "Martin J. Bligh" <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Linus Torvalds <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: "Martin J. Bligh" <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: "Martin J. Bligh" <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- From: Linus Torvalds <[email protected]>
- Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- Prev by Date: Re: pxa27x_udc -- support for usb gadget for pxa27x?
- Next by Date: Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- Previous by thread: Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- Next by thread: Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- Index(es):