Date: Mon, 27 Apr 2009 21:44:26 -0700
From: Elladan <elladan@eskimo.com>
To: linux-kernel@vger.kernel.org
Subject: Swappiness vs. mmap() and interactive response
Message-ID: <20090428044426.GA5035@eskimo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2341
Lines: 54

Hi,

So, I just set up Ubuntu Jaunty (using Linux 2.6.28) on a quad core phenom box,
and then I did the following (with XFS over LVM):

mv /500gig/of/data/on/disk/one /disk/two

This quickly caused the system to. grind.. to... a.... complete..... halt.
Basically every UI operation, including the mouse in Xorg, started experiencing
multiple second lag and delays.  This made the system essentially unusable --
for example, just flipping to the window where the "mv" command was running
took 10 seconds on more than one occasion.  Basically a "click and get coffee"
interface.

There was no particular kernel CPU load -- the SATA DMA seemed fine.

If I actively used the GUI, then the pieces I was using would work better, but
they'd start experiencing astonishing latency again if I just let the UI sit
for a little while.  From this, I diagnosed that the problem was probably
related to the VM paging out my GUI.

Next, I set the following:

echo 0 > /proc/sys/vm/swappiness

... hoping it would prevent paging out of the UI in favor of file data that's
only used once.  It did appear to help to a small degree, but not much.  The
system is still effectively unusable while a file copy is going on.

>From this, I diagnosed that most likely, the kernel was paging out all my
application file mmap() data (such as my executables and shared libraries) in
favor of total garbage VM load from the file copy.

I don't know how to verify that this is true definitively.  Are there some
magic numbers in /proc I can look at?  However, I did run latencytop, and it
showed massive 2000+ msec latency in the page fault handler, as well as in
various operations such as XFS read.  

Could this be something else?  There were some long delays in latencytop from
various apps doing fsync as well, but it seems unlikely that this would destroy
latency in Xorg, and again, latency improved whenever I touched an app, for
that app.

Is there any way to fix this, short of rewriting the VM myself?  For example,
is there some way I could convince this VM that pages with active mappings are
valuable?

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/