Linux memory usage and swap files

Bennett Todd bet at rahul.net
Wed Jul 7 14:08:37 PDT 2004


I've read up a bit on this, and here's what I came away with.

Some swap _should_ always improve performance; letting the kernel
evict completely unused pages (processes, or parts of processes, or
parts of libraries, that are never, ever accessed) makes more memory
available for disk buffer cache, and you can never have too much of
that.

However, a kernel constantly faces the decision: what pages should
be swapped out? When the pager's judgement doesn't agree with the
user, enabling swap can cause lost performance from the point of
view of the user.

The extreme illustrative example, consider someone who uses a
"typical" system. They're running a gigantic humongous bloated pig
of a "desktop", with hundreds and thousands of huge processes around
to provide all the drag-n-drop and animated whatsits and so forth.

Their memory working set is maybe 600MB or whatever, but they've got
a gig so they're happy, they think it's just slick.

At night they lock the screen and go home.

Sometime later, updatedb fires and does a whole-filesystem treewalk;
at this point, all the GUI crud has been idle for hours, so the
kernel reasonably decides to use the entire gig of RAM for disk
buffer (even though in the single linear pass over the whole disk
the actual benefit isn't that great, since there isn't that much
re-use).

The user comes in in the morning, and it takes only a minute or two
before the "*" start echoing as they type their password into the
lockscreen, but it's a half an hour before all the GUI crud is
swapped back in and the system starts to feel "normal" again.

So I exhaggerated some maybe, I don't especially like GUIs. But that
was the flavour of the complaint. That user is best pleased with no
swap allocated.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-chat/attachments/20040707/01bbefcf/attachment.sig>


More information about the lfs-chat mailing list