Some more results. I fixed the bug in your patch which
causes OOPS and I was thus able to measure the time it
takes to build a kernel. The patch which fixes the bug
is attached at the end of this email.
Now, a simple kernel compile (make clean; sync; time make -s vmlinux)
gives:
892.98user 56.66system 16:07.24elapsed 98%cpu
The same test using a stock kernel (ie. without coloring) typically
gives results like this:
843.97user 38.89system 14:48.82elapsed 99%cpu
Doesn't look too good. Let's have a look at what the fragmentation
of the buddy pools looks like after this kernel build:
119*8K 41*16K 632*32K 697*64k 322*128K 148*256K 0*512K 0*1024K 0*2048K 0*4096K
That's pretty bad. It almost certainly will get much worse over
time (and I'll be testing this over the next few hours).
Anyways, here is the fix for the bug in your patch.
--- mm/coloring.c.~2~ Tue Apr 11 16:50:32 2000
+++ mm/coloring.c Tue Apr 11 18:10:08 2000
@@ -57,6 +57,7 @@
break;
else
list_add(&page->list, &reject);
+ addr = 0;
}
/* If necessary, recurse to smaller blocks but not too deeply. */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:17 EST