From: Helge Hafting <helge.hafting@aitel.hist.no>
To: Grzegorz Kulewski <kangur@polcom.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Slow swapon for big (12GB) swap
Date: Mon, 10 Apr 2006 09:34:07 +0200 [thread overview]
Message-ID: <443A0A6F.2040500@aitel.hist.no> (raw)
In-Reply-To: <Pine.LNX.4.63.0604091338030.31989@alpha.polcom.net>
Grzegorz Kulewski wrote:
> Hi,
>
> I am using big swap here (as a backing for potentially huge tmpfs).
> And I wonder why swapon on such big (like 12GB) swap takes about 7
> minutes (continuous disk IO). Is this expected? Why it is like that?
> Can I do anything to speed it up? Or maybe remove it into the
> background with low priority or something like that?
I don't know why it is slow. But you can certainly do something like:
nice swapon /dev/yourdisk &
Then it will happen in the background and with low priority. Of course,
you can't start filling your tmpfs until this completes.
I don't think tmpfs+swap was made with this sort of use in mind,
so you may want to test the performance when you fill up such a
tmpfs, and compare to the performance of /tmp on a 12GB
ordinary filesystem. It seems to me that the advantage of /tmp on
tmpfs is lost completely if most of it has to be written to disk anyway.
(Ordinary filesystems are cached too, the "tmpfs advantage" is that
truly temporary (but possibly long-lived) files are never written
to disk _if_ you have enough memory. /tmp on a plain filesystem
is just as fast due to caching, but may delay other use of the
disk as the ordinary filesystem writes stuff out so it will be
saved for the future.)
If you go for a plain filesystem, consider ext2 which is simple faster
than journalling systems like ext3. You don't need the added
safety for temporary stuff. Now ext2 have long fsck times if
something goes wrong, but you don't need to fsck this filesystem.
Have your bootscripts run mke2fs at boot instead of fsck for
this filesystem. mke2fs on 12GB is fast, much faster than
7 minutes. Expect a few seconds only.
Helge Hafting
next prev parent reply other threads:[~2006-04-10 7:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-09 11:45 Grzegorz Kulewski
2006-04-10 7:34 ` Helge Hafting [this message]
2006-04-10 10:17 ` Grzegorz Kulewski
2006-04-11 11:30 ` Jan Engelhardt
2006-04-11 11:46 ` linux-os (Dick Johnson)
2006-04-10 7:40 ` Andrew Morton
2006-04-10 9:44 ` Antonio Vargas
2006-04-10 10:25 ` Grzegorz Kulewski
2006-04-10 9:54 ` Andrew Morton
2006-04-10 11:45 ` Grzegorz Kulewski
2006-04-10 10:27 ` Con Kolivas
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=443A0A6F.2040500@aitel.hist.no \
--to=helge.hafting@aitel.hist.no \
--cc=kangur@polcom.net \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®