Re: Memory compaction and mlockall()

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2019-08-12 16:59:00 [+0200], Vlastimil Babka wrote:
> On 7/11/19 11:43 AM, Sebastian Andrzej Siewior wrote:
> > On 2019-07-10 11:21:19 [-0700], Yang Shi wrote:
> >>
> >> compaction should not isolate unevictable pages unless you have
> >> /proc/sys/vm/compact_unevictable_allowed set.
> > 
> > Thank you. This is enabled by default. The documentation for this says
> > | … compaction is allowed to examine the unevictable lru (mlocked pages) for
> > | pages to compact.…
> > 
> > so it is actually clear once you know where to look.
> > If I read this correct, the default behavior was to ignore mlock()ed
> > pages for compaction then commit
> >   5bbe3547aa3ba ("mm: allow compaction of unevictable pages")
> > 
> > came along in v4.1-rc1 and changed that behaviour. Is it too late to
> > flip it back?
> 
> 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. …

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.

Sebastian