-
-
Notifications
You must be signed in to change notification settings - Fork 34
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
Add support for FFMA without hugepages and using only mmap #296
Conversation
…che, also add support for mmap direct allocations
…o allocate a fixed address via mmap
…rge enough for errors messages
…i_recv after the refactoring
…fy the test to use a 160MB string instead of 256MB
… re-initialized afterwards
…er the ffma tests
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #296 +/- ##
==========================================
- Coverage 81.71% 81.70% -0.02%
==========================================
Files 161 163 +2
Lines 11009 11031 +22
==========================================
+ Hits 8996 9012 +16
- Misses 2013 2019 +6
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 3 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
This branch adds support for Fast Fixed Memory Allocator (FFMA) to function without hugepages and using only mmap.
Overall, it makes FFMA more versatile by allowing it to work without hugepages and with only mmap, which can improve its performance and efficiency in certain scenarios, but most importantly as FFMA doesn't suffer from memory fragmentation makes it a perfect choice for a long-running software like cachegrand as reduce the scope of any garbage collector that will be implemented down the line.
The only downside, currently, is that the storage_db has to operate using blocks of 64kb and this limits the maximum size of the chunks to about ~170MB of data.
This limitation will be removed with a future PR.
There are also some additional PRs planned to make FFMA less dependant on malloc and rely instead on mmap for its own internal allocations.