-
Notifications
You must be signed in to change notification settings - Fork 886
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
hoping the new version coming soon #972
Comments
Well, a fresh version is coming soon v1.8.8 and v2.1.8 -- hopefully next week. However, with huge pages there will always be more memory usage since it is a 1 GiB huge page pinned in memory -- we cannot purge any memory inside such huge pages :-) . Also, a 10% difference with respect to some other allocator can always be the case -- we are trying but it often depends on workloads etc, and sometimes memory usage is in tension with scalable performance. (ps. having said this, you might want to try out the latest |
|
@daanx, hi daanx, I see that the last version is released in May, is there any news about the next release?
When I use mimalloc with pure 1GB hugepages, it comes to a 40% memory usage higher than nomal 4KB page, and with normal 4KB page, the RSS of mimalloc is still 10% higher than jemalloc, is there any clue? I have to let RocksDB work on hugepage, so mimalloc is the only choice.
I trust mi and je are both SOTA mallocs, so hoping the next version can improve this.
The text was updated successfully, but these errors were encountered: