Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exploit thread-local cache locality #24

Open
connortsui20 opened this issue Aug 14, 2024 · 0 comments
Open

Exploit thread-local cache locality #24

connortsui20 opened this issue Aug 14, 2024 · 0 comments

Comments

@connortsui20
Copy link
Owner

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.

connortsui20 pushed a commit that referenced this issue Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant