Tuning-advise for soft-realtime systems
linuxhippy at gmail.com
Fri Mar 18 02:12:26 PDT 2016
Thank you for your suggestions. Disabling dirty page purging helped a
lot, as did disabling transparent huge pages.
Worst-case latency for our test is now down to ~140µs compared to
glibc with ~100µs.
Am I right that the only syscall left is now the nmap for requesting new chunks?
Is there any way to preallocate the memory chunks used by jemalloc -
as there will be only one large-footpint application on the system, I
could afford to allocate e.g. 75% for this single high-priority
Thank you & best regards, Clemens
2016-03-15 19:27 GMT+01:00 Jason Evans <jasone at canonware.com>:
> On Mar 14, 2016, at 10:52 AM, Clemens Eisserer <linuxhippy at gmail.com> wrote:
>> I am currently evaluating jemalloc for a soft-realtime system where
>> worst-case latency is of concern.
>> When allocating areas of random size honoring the size-distribution
>> which is to be expected, usually latency is of no concern.
>> However, from time to time there are latency spikes of ~300
>> microseconds for a single malloc especially for mid-sized allocations
>> (e.g. 1024byte).
>> My guess is those latency spikes arise when jemalloc requests
>> additional memory for it's arena's from the kernel.
>> Are there any tuning knobs to reduce the duration of those spikes and
>> instead increasing there frequency?
> The top suggestions I can think of are to disable unused dirty page purging, and to increase the chunk size to the largest size you can tolerate in terms of memory usage.
More information about the jemalloc-discuss