The buffer pool structure introduced here is really interesting, it's the second one I've read of lately that introduces a tiered frame-size architecture.
So rather than each frame slot being, say, PAGE_SIZE, you have multiple frame slot sizes in the buffer pool.
What is different about this gVisor implementation is that the frame sizes seemed to be all mixed up with each other?
IE, from the example image, the below seems like a valid layout:
[1024, 512, 256]
The other implementation that I am aware of (Umbra, a research DB) uses multiple, independent pools which are overlayed on top of each other using independent mmap() anonymous calls.
This is more understandable (to me) because you can use a hash map look up (well, more likely in production, some kind of "&" with hash keys) to index into the size tier you want, like:
So rather than each frame slot being, say, PAGE_SIZE, you have multiple frame slot sizes in the buffer pool.
What is different about this gVisor implementation is that the frame sizes seemed to be all mixed up with each other?
IE, from the example image, the below seems like a valid layout:
The other implementation that I am aware of (Umbra, a research DB) uses multiple, independent pools which are overlayed on top of each other using independent mmap() anonymous calls.https://db.in.tum.de/~freitag/papers/p29-neumann-cidr20.pdf
This is more understandable (to me) because you can use a hash map look up (well, more likely in production, some kind of "&" with hash keys) to index into the size tier you want, like: