From e29f0e294ac841e2036fe514df4ed66f5d0ec46f Mon Sep 17 00:00:00 2001
From: dzwdz
Date: Tue, 16 Jul 2024 02:34:03 +0200
Subject: 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.
---
 src/libk/include/camellia/execbuf.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'src/libk')

diff --git a/src/libk/include/camellia/execbuf.h b/src/libk/include/camellia/execbuf.h
index 8ffabad..a5704a2 100644
--- a/src/libk/include/camellia/execbuf.h
+++ b/src/libk/include/camellia/execbuf.h
@@ -1,7 +1,7 @@
 #pragma once
 /* the instruction format is bound to change, atm it's extremely inefficient */
 
-#define EXECBUF_MAX_LEN 2048
+#define EXECBUF_MAX_LEN 1024
 
 /* takes 6 arguments */
 #define EXECBUF_SYSCALL 0xF0000001
-- 
cgit v1.2.3