Re: Memory compaction and mlockall()

[Vlastimil Babka <vbabka@suse.cz>]

On 8/12/19 5:54 PM, Sebastian Andrzej Siewior wrote:
> On 2019-08-12 16:59:00 [+0200], Vlastimil Babka wrote:
>> I would say that enabled is a better default wrt benefits for the
>> majority of systems. This was assuming that mlock() is primarily used to
>> prevent sensitive data (crypto keys) from hitting swap, not to give
>> latency guarantees. You could perhaps argue that enabling PREEMPT_RT
>> might change the default, but it's somewhat subtle.
> 
> A different behaviour depending on PREEMPT_RT is bad. 
> From the mlock(2) page:
> 
> |NOTES
> |
> |Memory locking has two main applications: real-time algorithms and
> |high-security data processing. Real-time applications require deterministic
> |timing, and, like scheduling, paging is one major cause of unexpected program
> |execution delays. …
> |
> |Real-time processes that are using mlockall() to prevent delays on page faults
> |should reserve enough locked stack pages before entering the time-critical
> |section, so that no page fault can be caused by function calls. …

Ah, I see, so it is documented for time-critical stuff.

> So if we are not going to revert that, then I would need to update man
> page to reflect that we now have an additional knob to consider in order
> to disable page faults on mlock()ed pages.

If we're going to update man page, then there's also auto NUMA balancing
that can cause minor faults and migrations, AFAIK.

> Sebastian
>