To: Daniel Drake <ddrake@brontes3d.com>
Cc: Arjan van de Ven <arjan@infradead.org>, linux-mm@kvack.org,
       linux-kernel@vger.kernel.org
Subject: Re: speeding up swapoff
References: <1188394172.22156.67.camel@localhost>
	<20070829073040.1ec35176@laptopd505.fenrus.org>
	<1188398683.22156.77.camel@localhost>
From: Andi Kleen <andi@firstfloor.org>
Date: 02 Sep 2007 00:20:22 +0200
In-Reply-To: <1188398683.22156.77.camel@localhost>
Message-ID: <p73fy1yvxi1.fsf@bingen.suse.de>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1145
Lines: 22

Daniel Drake <ddrake@brontes3d.com> writes:
> 
> It's more-or-less a real life problem. We have an interactive
> application which, when triggered by the user, performs rendering tasks
> which must operate in real-time. In attempt to secure performance, we
> want to ensure everything is memory resident and that nothing might be
> swapped out during the process. So, we run swapoff at that time.

If the system gets under serious memory pressure it'll happily discard
your text pages too (and later reload them from disk). The same
for any file data you might need to access.

swapoff will only affect anonymous memory, but not all the other
memory you'll need as well.

There's no way around mlock/mlockall() to really prevent this.

Still even with that you could still lose dentries/inodes etc which
can also cause stalls. The only way to keep them locked
is to keep the files always open.

-Andi
-
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/