https://bugs.linaro.org/show_bug.cgi?id=3774
--- Comment #11 from Josep Puigdemont <josep.puigdem...@linaro.org> --- The issue here seems to be the same as for bug 3867. When allocating a huge page, the kernel zeroes it out before handing it over to user space, and this is one of the causes of the delays. Another cause is that there is a single lock taken when entering any of the shared memory module functions, and released only on exit (roughly speaking), causing lock contention for other threads and CPU usage. Due to the nature of this test application, which has many threads allocating and freeing shared memory in rather rapid succession, all of the above becomes a problem that results in the delays observed. Maybe this is not an issue for real world applications, which probably allocate memory once at start-up or, at least, not so often. One initial idea to mitigate this problem was to keep the huge pages that where to be freed in a list of "available" pages rather than closing the file descriptor. However, this approach would create problems with "process mode" threads in ODP, as we would need to find a way to know when all threads have freed a given huge page (it might be possible to implement this functionality in fdserver, but it doesn't feel right). -- You are receiving this mail because: You are on the CC list for the bug.
