| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This is meant to facilitate a syscall for returning from interrupts, which
will actually work in the general case as opposed to the current hack, which
only works if the interrupt occured during a syscall (which is correct... for
now).
|
|
I'm storing more information in less space. Win-win.
|
|
This will both let me save space in the allocation header, and make the
debugprint more readable.
|
|
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.
|
|
Yay for guaranteed O(1) insertions, even if iostress seems a bit slower.
|
|
|
|
* firstfreepage now updates properly, preventing a crash (oops)
* kfree only wipes the length of the allocation, not the entire page - which
should make it easier to see the performance impact of the pagealloc changes
|
|
The bitmap functions now accept page addresses so I don't have to handle
raw bitmap indexes, which was kinda complex.
kmalloc_sanity is now not visible to other code as it wasn't really that useful
in the first place.
|
|
This will likely be changed back, but for the time being it will let me
implement a better allocator without too much effort.
|
|
|
|
|
|
|
|
|
|
|
