Xorg swapping: bug or expected?

[Adam Jackson]

On Mon, 2016-01-11 at 23:37 +0100, Francois wrote:

> My question is: is this normal? Do we expect Xorg to swap like any other
> program, or does Xorg (should) mlock some of the memory it uses to avoid
> swapping? Do you think there is anything else to investigate, or is this
> just working as designed?

Well it's working as written, whether that can be called "designed" is
perhaps arguable. The X server doesn't attempt to mlock itself, and
it's not even straightforward to figure out how much it would need to
lock to remain responsive, even assuming we could agree what
"responsive" was supposed to mean. If we wanted only that cursor
updates remain smooth that's still scattered across the server core and
whichever input driver is in use. If you want window updates to happen
promptly suddenly you're talking about potentially every pixmap held by
every application... (and also the compositor, or else every
application, since repaints will likely involve IPC).

That's not to say mlock couldn't help, but once you get into paging
like this, if X's pageins get scheduled behind other disk i/o we've
lost and there's nothing X can really do about that. We're ultimately
at the mercy of the kernel's block scheduler in any case.

That said, if dd is consuming so much memory that it's pushing X out of
the working set, I would tend to consider that a flaw in dd (or the
user's invocation of it) first. After all dd's working set size is
effectively bounded: there will be some optimal buffer size which gets
within epsilon of peak read throughput, and for all but the most exotic
hardware that's not going to be in the gigabyte range.

- ajax