Messages in this thread | | | Date | Thu, 03 Nov 2005 10:17:12 -0800 | From | "Martin J. Bligh" <> | Subject | Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 |
| |
>> > For amusement, let me put in some tritely oversimplified math. For the >> > sake of arguement, assume the free watermarks are 8MB or so. Let's assume >> > a clean 64-bit system with no zone issues, etc (ie all one zone). 4K pages. >> > I'm going to assume random distribution of free pages, which is >> > oversimplified, but I'm trying to demonstrate a general premise, not get >> > accurate numbers. >> >> that is VERY over simplified though, given the anti-fragmentation >> property of buddy algorithm > > Indeed. I write a program at one time doing random allocation and > de-allocation and looking at what the output was, and buddy is very good > at avoiding fragmentation. > > These days we have things like per-cpu lists in front of the buddy > allocator that will make fragmentation somewhat higher, but it's still > absolutely true that the page allocation layout is _not_ random.
OK, well I'll quit torturing you with incorrect math if you'll concede that the situation gets much much worse as memory sizes get larger ;-)
For order > 1 allocs, I think it's fixable. For order > 1, I think we basically don't have a prayer on a largish system under pressure.
M.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |