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/kernel/malloc.h | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'src/kernel/malloc.h') 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 #include -/* 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); -- cgit v1.2.3