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 >
