diff options
author | dzwdz | 2024-07-16 02:34:03 +0200 |
---|---|---|
committer | dzwdz | 2024-07-16 02:34:03 +0200 |
commit | e29f0e294ac841e2036fe514df4ed66f5d0ec46f (patch) | |
tree | d37c40bdfecb153ab580f6119bf71294f3d77e93 /toolchain | |
parent | 4fbb7e3c43440bd7eb4bf081c5be51dfe6f6e088 (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 'toolchain')
0 files changed, 0 insertions, 0 deletions