summaryrefslogtreecommitdiff
path: root/src/libk/include
diff options
context:
space:
mode:
authordzwdz2024-07-16 02:34:03 +0200
committerdzwdz2024-07-16 02:34:03 +0200
commite29f0e294ac841e2036fe514df4ed66f5d0ec46f (patch)
treed37c40bdfecb153ab580f6119bf71294f3d77e93 /src/libk/include
parent4fbb7e3c43440bd7eb4bf081c5be51dfe6f6e088 (diff)
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.
Diffstat (limited to 'src/libk/include')
-rw-r--r--src/libk/include/camellia/execbuf.h2
1 files changed, 1 insertions, 1 deletions
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