Tuning-advise for soft-realtime systems

[Clemens Eisserer]

Hi Jason,

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

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