From: Daniel Drake <ddrake@brontes3d.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: speeding up swapoff
Date: Wed, 29 Aug 2007 10:44:43 -0400 [thread overview]
Message-ID: <1188398683.22156.77.camel@localhost> (raw)
In-Reply-To: <20070829073040.1ec35176@laptopd505.fenrus.org>
On Wed, 2007-08-29 at 07:30 -0700, Arjan van de Ven wrote:
> > My experiments show that when there is not much free physical memory,
> > swapoff moves pages out of swap at a rate of approximately 5mb/sec.
>
> sounds like about disk speed (at random-seek IO pattern)
We are only using 'standard' seagate SATA disks, but I would have
thought much more performance (40+ mb/sec) would be reachable.
> before you go there... is this a "real life" problem? Or just a
> mostly-artificial corner case? (the answer to that obviously is
> relevant for the 'should we really care' question)
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 there is a decent number of pages swapped out, the user sits for a
while at a 'please wait' screen, which is not desirable. To throw some
numbers out there, likely more than a minute for 400mb of swapped pages.
Sure, we could run the whole interactive application with swap disabled,
which is pretty much what we do. However we have other non-real-time
processing tasks which are very memory hungry and do require swap. So,
there are 'corner cases' where the user can reach the real-time part of
the interactive application when there is a lot of memory swapped out.
> Another question, if this is during system shutdown, maybe that's a
> valid case for flushing most of the pagecache first (from userspace)
> since most of what's there won't be used again anyway. If that's enough
> to make this go faster...
Shutdown isn't a concern here.
> A third question, have you investigated what happens if a process gets
> killed that has pages in swap; as long as we don't page those in but
> just forget about them, that would solve the shutdown problem nicely
> (since we kill stuff first anyway there)
According to top, those pages in swap disappear when the process is
killed. So, I don't think there are any swap-related performance issues
on the shutdown path.
Thanks.
--
Daniel Drake
Brontes Technologies, A 3M Company
http://www.brontes3d.com/opensource
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-08-29 14:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-29 13:29 Daniel Drake
2007-08-29 14:30 ` Arjan van de Ven
2007-08-29 14:36 ` Oliver Neukum
2007-08-29 16:04 ` Hugh Dickins
2007-08-29 16:18 ` Oliver Neukum
2007-08-29 14:44 ` Daniel Drake [this message]
2007-08-29 15:12 ` Juergen Beisert
2007-08-30 15:57 ` Bill Davidsen
2007-09-01 22:20 ` Andi Kleen
2007-08-29 15:58 ` Hugh Dickins
2007-08-29 15:36 ` Hugh Dickins
2007-08-30 8:27 ` Eric W. Biederman
2007-08-30 10:36 ` Hugh Dickins
2007-08-30 15:05 ` Daniel Drake
2007-08-29 16:08 ` Lee Schermerhorn
[not found] <fa.j/pO3mTWDugTdvZ3XNr9XpvgzPQ@ifi.uio.no>
[not found] ` <fa.ed9fasZXOwVCrbffkPQTX7G3a7g@ifi.uio.no>
[not found] ` <fa./NZA3biuO1+qW5pW8ybdZMDWcZs@ifi.uio.no>
2007-08-30 1:37 ` Robert Hancock
2007-08-30 13:55 ` Helge Hafting
2007-08-30 14:06 ` Xavier Bestel
2007-08-30 14:06 ` Helge Hafting
2007-08-30 14:14 ` Xavier Bestel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1188398683.22156.77.camel@localhost \
--to=ddrake@brontes3d.com \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox