kernel: use a slab allocator for kmalloc

For a while during development it managed to be faster than the old allocator
despite having more overhead, probably because it makes better use of the
cache. It no longer is - not sure why. The code definitely could be optimized
to hell, though, and it'd probably recover its original edge.

Non-power-of-2 sizeclasses would be really useful, as I could then e.g.
fit four processes into a page instead of three, but I think implementing them
"well" would be too complicated for now.

In hindsight arbitrary allocation descriptions were probably a bad idea too.
I've kept them in for now, but I'll switch to an enum of allocation types soon.
I think I can fit all the per-allocation state (size+type) in 2 bytes.

There are so few allocations in the kernel that I no longer care about the
backtraces, so I'm leaving them out.

The "large" allocations could probably be tested with execbuf in userland, so
I might actually implement them soon too.

1 files changed, 6 insertions, 4 deletions

diff --git a/src/kernel/malloc.h b/src/kernel/malloc.h
index 436d899..bda2745 100644
--- a/src/kernel/malloc.h
+++ b/src/kernel/malloc.h
@@ -3,10 +3,12 @@
 #include <shared/mem.h>
 #include <stddef.h>
 
-/* This seems to be fine for now, and it means that i don't need to concern
- * myself with allocating contiguous pages for now, which is way easier to do
- * well. */
-#define KMALLOC_MAX 2048
+/* This seems to be fine for now.
+ * KMALLOC_MAX >= 2048 would require extending kmalloc with a new allocation
+ * type. KMALLOC_MAX >= 4096 would require a new (Buddy?) page allocator.
+ * Both are pretty easy, but I don't want to maintain what would currently be
+ * dead code. */
+#define KMALLOC_MAX 1024
 
 void mem_init(void *memtop);
 void mem_reserve(void *addr, size_t len);