Performance of Emacs using glibc's malloc

1. Worklod (mtraceEMACS.mtr.9294)

1.1. Analysis

On 2020-11-23 we received a malloc trace via https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43389 that indicated that there could be an interaction issue with Emacs and the glibc malloc implementation. An initial malloc API trace was provided by Jean Lous as mtraceEMACS.mtr.9294. This trace was modelled via the simulator (trace_run) using the released glibc 2.31 (2020-02-01) and the current development glibc 2.33 (to be released 2021-02-01).

In both cases the behaviour of the trace is the same and doesn't exhibit any pathological algorithmic issues. Demand in the application rises to a peak of ~100MiB and then falls. As the application demand falls the glibc algorithms keep the 100MiB watermark limit for future reuse by the applcation. Longer tracing is going to be required to be able to observe a ratcheting effect if there is one based on the application workload.

There are 8 threads seen during the trace. The simulation shows the VMA steps up in 8 x 64MiB steps which is expected given that as each thread does a first allocation, and we haven't reached the arena limit, it will reserve a 64MiB block for the first heap in the arena. The heap reservation is only a VMA reservation and does not impact RSS usage.

1.2. Conclusion

The current trace doesn't show any algorithmic effects for RSS that do not match API demand. The black line, API demand, largely mirrors the blue line of actual RSS used, but with a small offset. The actual RSS usaged, blue line, remains constant after API demand is withdrawn, this is expected and in line with glibc malloc algorithm behaviour of keeping memory cached in userspace for reuse. With at least 4 cores on a 64-bit system with 8 threads we expect at least a reservation of 512MiB for the initial heaps and see that in the output.

The trace does not show any large memory usage scenarios, or the simulator could not reproduce them. There could be other interactions including kernel VMA layout, and libraries using sbrk or mmap in the background, which we don't account for here.

emacs_GLIBC233_fig1.png

emacs_GLIBC233_fig2.png

emacs_GLIBC233_fig3.png

None: emacs-malloc (last edited 2020-11-23 19:56:04 by CarlosODonell)