From: Joel Krauska <jkrauska@gmail.com>
To: linux-mm@kvack.org
Subject: swapoff throttling and speedup?
Date: Wed, 03 Jun 2009 10:01:39 -0700 [thread overview]
Message-ID: <4A26AC73.6040804@gmail.com> (raw)
On occasion we need to unswap a system that's gotten unruly.
Scenario: Some leaky app eats up way more RAM than it should, and pushes
a few gigs of the running system in to swap. The leaky app is killed,
but there's still lots of good stuff sitting in swap that we need to tidy
up to get the system back to normal performance levels.
The normal recourse is to run
swapoff -a ; swapon -a
I have two related questions about the swap tools and how they work.
1. Has anyone tried making a nicer swapoff?
Right now swapoff can be pretty aggressive if the system is otherwise
heavily loaded. On systems that I need to leave running other jobs,
swapoff compounds the slowness of the system overall by burning up
a single CPU and lots of IO
I wrote a perl wrapper that briefly runs swapoff
and then kills it, but it would seem more reasonable to have a knob
to make swapoff less aggressive. (max kb/s, etc)
It looked to me like the swapoff code was immediately hitting kernel
internals instead of doing more lifting itself (and making it
obvious where I could insert some sleeps)
Has anyone found better options here?
2. A faster(multithreaded?) swapoff?
>From what I can tell, swapoff is single threaded, which seems to make
unswapping a CPU bound activity.
In the opposite use case of my first question, on systems that I /can/
halt all the running code (assuming if they've gone off the deep end and have
several gigs in SWAP) it can take quite a long time for unswap to
tidy up the mess.
Has anyone considered improvements to swapoff to speed it up?
(multiple threads?)
I'm hoping others have been down this road before.
As a rule, we try to avoid swapping when possible, but using:
vm.swappiness = 1
But it does still happen on occasion and that lead to this mail.
Cheers,
Joel
--
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 reply other threads:[~2009-06-03 17:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-03 17:01 Joel Krauska [this message]
2009-06-04 2:04 ` KAMEZAWA Hiroyuki
2009-06-04 2:43 ` Joel Krauska
2009-06-04 2:54 ` KAMEZAWA Hiroyuki
2009-06-04 15:50 ` Hugh Dickins
2009-06-04 16:25 ` KAMEZAWA Hiroyuki
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=4A26AC73.6040804@gmail.com \
--to=jkrauska@gmail.com \
--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