You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Right now, every single
FrameGroup
is visible to every single thread. Or in other words, every thread can access everyFrameGroup
.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
FrameGroup
s to each thread, where when a thread picks a randomFrameGroup
(64 frames), it first looks through the dedicated thread-localFrameGroup
s 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 ofFrameGroup
s.It might also be possible to have variable sized
FrameGroup
s. 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
FrameGroup
s, it would probably be the best interest to allocate all virtual memory up front withmmap
. This would also pave the way for a future implementation of variable-sized page classes like those in the Umbra system.The text was updated successfully, but these errors were encountered: