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

hoping the new version coming soon #972

Open
979357361 opened this issue Dec 20, 2024 · 2 comments
Open

hoping the new version coming soon #972

979357361 opened this issue Dec 20, 2024 · 2 comments

Comments

@979357361
Copy link

@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.

@daanx
Copy link
Collaborator

daanx commented Dec 23, 2024

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 dev3-bin branch which has a new backend allocation mechanism which under certain workloads uses much less memory. This is still in alpha stage though).

@979357361
Copy link
Author

Well, a fresh version is coming soon v1.8.8 and v2.1.8 -- hopefully next week.
-Well, glad to here that!

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 :-) .
-That sounds like a problem.
We will repeatedly alloc and free same size memory block, if a block is freed and waiting purge (which can't be done in a hugepage), then another malloc call with same size comes, will the freed block be re-used first for allocation? If not, it sounds like we have lost the block forever, and hugepages will become unusable as time goes by?
Is there any setting to improve the efficiency of hugepages?

(ps. having said this, you might want to try out the latest dev3-bin branch which has a new backend allocation mechanism which under certain workloads uses much less memory. This is still in alpha stage though).
-We has tried this patch and it seems not help.

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

2 participants