Exploit thread-local cache locality #24
Description
Right now, every single FrameGroup is visible to every single thread. Or in other words, every thread can access every FrameGroup.
This is both a good and a bad thing - we want each thread to be able to share data with another thread so we don't have to do multiple I/Os for the same piece of data. However, we also would like to exploit cache locality for each of threads.
We could potentially reduce cache misses by dedicating a few FrameGroups to each thread, where when a thread picks a random FrameGroup (64 frames), it first looks through the dedicated thread-local FrameGroups to see if there are any immediately free frames , and then if it figures that there are no more free frames, it then reaches for the global pool of FrameGroups.
It might also be possible to have variable sized FrameGroups. Right now they are all fixed to 64 frames, but there is nothing in the code that assumes all frame groups are the same size except in the frame ID logic the initial allocation, both of which can be changed easily.
Regardless, by introducing a dedicated thread-local FrameGroups, it would probably be the best interest to allocate all virtual memory up front with mmap. This would also pave the way for a future implementation of variable-sized page classes like those in the Umbra system.