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 _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
