-
Notifications
You must be signed in to change notification settings - Fork 18
Add jemalloc by default(3/5) #3
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
Conversation
NurKeinNeid
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please drop unrelated commits first and you're missing system/core.
Sure thank you for the feedback, i have droped all the unrelated commits and i can't find the missing commit for system/core, i will search for it and make a new pr later. |
NurKeinNeid
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weren't you wondering where 4/4 was? You should also always look at the original author at first. It originally comes from AOSPA.
i am sorry i assumed external_jemalloc as the last commit for it. I wasn't aware of the origin author, I have given proper credited to all the new author with the force push. |
a7303e2 to
277e12d
Compare
NurKeinNeid
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand why you force pushed it and changed authorship. I didn't mention that at all. Everything was fine, now it's wrong.
I will make it right now. Thank you. |
Overall, jemalloc performs 10-20% better than Scudo while consuming equivalent amount of memory in system/extra's real-world memory_replay traces: https://docs.google.com/spreadsheets/d/1E5d_YcU04i8zA-V0vcJgilONGICvR6ynfYGMAvSnMvg/edit?usp=sharing Scudo performs fairly well for a hardened memory allocator, but we're optimizing for performance. Tests were performed by statically linking memory_replay under PA Sapphire branch. Android userspace has been stopped before performing all benchmarks, and each test was executed 10 times with an idle detector in between to reduce noise and errors. The entire test took about 18 hours: https://github.com/arter97/android_memory_replay_helper Few notes: - jemalloc shipped with android-12.1.0_r5, v5.1.0, performs consistently better than v5.2.1, especially with the camera trace, but generally consumes more memory. - jemalloc v5.3.0 is not benchmarked yet due to on going Android compatibility issues: jemalloc/jemalloc#2279 - Scudo from android-12.1.0_r8 consumes 5.5% less memory compared to Qualcomm's Scudo, and the performance is equivalent (0.2% better). This commit has been inspired from ProtonAOSP/android_bionic@b220489 Change-Id: I84264c07b1bc8c9dc69fd1dde48a2c7c9609d82d Signed-off-by: MxkulSharma <sharmamukul06175@gmail.com>
NurKeinNeid
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution. Looks good to me now but Pixels don't like these changes. I need to add the changed repos to be excluded in pixel branch manifest. But next weekend's I will be very busy with QPR2.
ok no problem so should i keep these pr open or should i close them or do i need to exclude these repo from pixel branch? |
|
Just keep the pull requests open. I have a lot of local uncommited changes because of qpr2 and cant tell yet if I will merge to qpr1 or qpr2 only and when I will find time. |
|
Still no system/core commit |
Jemalloc by default is good because of :
Reduced Fragmentation: jemalloc employs sophisticated algorithms to allocate memory in a way that minimizes fragmentation. This fragmentation occurs when freed memory becomes scattered in small chunks, making it difficult to allocate larger blocks efficiently. jemalloc's approach helps maintain contiguous memory regions, leading to faster allocation and deallocation operations.
jemalloc excels in multi-threaded environments. It utilizes thread-caching mechanisms and per-thread allocation arenas to minimize contention and improve memory access speed for concurrent threads.
jemalloc provides valuable debugging features that can aid in troubleshooting memory-related issues within the operating system. These tools can help pinpoint memory leaks, identify memory usage patterns, and diagnose allocation/deallocation problems, leading to a more stable and reliable system.
It also make's the device perform well at higer load's and improve performance.
You can check other PR regarding this from these Links.
Build (1/5)
Build_soong (2/5)
Bionic (3/5)
external_jemalloc_new (4/5)
manifest (5/5)
System_core