From: Helge Hafting <helgehaf@idb.hist.no>
To: "Peter Wächtler" <pwaechtler@loewe-komp.de>,
linux-kernel@vger.kernel.org
Subject: Re: kswapd eats the cpu without swap
Date: Thu, 02 Aug 2001 12:49:37 +0200 [thread overview]
Message-ID: <3B693040.2185C3AE@idb.hist.no> (raw)
In-Reply-To: <Pine.A41.4.31.0108020049360.61934-100000@pandora.inf.elte.hu> <3B691F87.2182A1BA@loewe-komp.de>
Peter Wächtler wrote:
> when the system runs low on memory (on a 64MB setop box like device
> with _no_ swap partition/file), the harddisk gets very active and
> the system does not respond for 1-5 seconds.
> The VM (in mm/oom_kill.c) is killing the "memory hog" (simple program
> that calls malloc() in a loop and touching the mem). I think the
> amount of "busyness" depends on the size of malloc chunks. If they
> are bigger the process gets killed faster.
>
> Until now, I don't understand what is happening. Several subsystems
> in the kernel compete for memory: dentry cache, buffer cache, VM
> that wants at least /proc/sys/vm/freepages free.
> Is demand loading involved? Does the VM quashes text pages when
> running low on memory? What about relocation then?
>
> Or simpler: what keeps the harddisk so busy?
The VM system drop unwriteable pages (i.e. program code) when out of
memory. This is the only kind of "swapping" when you don't
have a swap partition/file. It will of course also empty the
various disk caches (page cache, buffer cache, inode/dentry caches)
so every little file operation might need several disk accesses.
Getting really low on memory with no swap device means that you
have almost no program code loaded. Data is unswappable without
a device and fills memory, every little piece of code that needs
execution have to be re-loaded from the executables on disk.
This is why your disk get busy. Your machine is trashing.
Trashin happens both with and without a swap device.
Having swap can help a lot - the VM subsystem will then be able to
page out old unused data leaving more room for often-used code.
You will then get a lot better performance even though you
don't have more RAM. Of course you may run into trashing with
a swap device too - but it happens later after using much more
memory. With luck you don't get that far with normal use. If
you do - get more RAM.
Helge Hafting
next prev parent reply other threads:[~2001-08-02 10:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-01 22:08 kswapd eats the cpu without swap BERECZ Szabolcs
2001-08-01 22:23 ` BERECZ Szabolcs
2001-08-01 22:58 ` BERECZ Szabolcs
2001-08-02 9:38 ` Peter Wächtler
2001-08-02 10:49 ` Helge Hafting [this message]
2001-08-03 22:21 ` Marcelo Tosatti
2001-08-06 22:48 ` BERECZ Szabolcs
2001-08-06 23:21 ` Daniel Phillips
2001-08-06 22:47 ` Marcelo Tosatti
-- strict thread matches above, loose matches on Subject: below --
2001-08-02 20:47 BERECZ Szabolcs
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=3B693040.2185C3AE@idb.hist.no \
--to=helgehaf@idb.hist.no \
--cc=linux-kernel@vger.kernel.org \
--cc=pwaechtler@loewe-komp.de \
/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