From: Alexander Gretencord <arutha@gmx.de>
To: linux-kernel@vger.kernel.org
Cc: Con Kolivas <kernel@kolivas.org>
Subject: Re: Swapping in 2.6.10 and 2.6.11.11 on a desktop system
Date: Mon, 20 Jun 2005 21:09:50 +0200 [thread overview]
Message-ID: <200506202109.51059.arutha@gmx.de> (raw)
In-Reply-To: <200506161416.03569.kernel@kolivas.org>
On Thursday 16 June 2005 06:16, you wrote:
> echo 100 > /proc/sys/vm/mapped
Doesn't work either.
What I do to test this is the following:
Start X with KDE, start a Konqueror instance, a firefox, eclipse and vmware.
This increases memory load to about 250MB. Then I start os inside the vmware
virtual machine. This increases memory allocation because the guest operating
system has to exist somewhere and generates IOs while the virtual disk is
accessed. With mapped=100 it takes longer until the system begins to swap but
once it has begun swapping I get this:
total used free shared buffers cached
Mem: 503 498 5 0 10 412
-/+ buffers/cache: 75 428
Swap: 494 230 264
It does not matter which patch I am using, once the magical "begin
swapping"-mark is reached, real ram usage drops to a bare minimum and cache
usage goes up. The IO cache is probably not even used as there are virtually
no reusable parts.
The problem is the kernel thinking in the wrong direction (freeing ram for
disk cache). Maybe that's ok for a streaming server which uses 10MB of RAM
for code and internal data and is constantly accessing the same 400MB of
streaming video data. Or a webserver serving a big amount of static pages
etc. but it is not ok for my desktop workload where I have about 400MB of
data belonging to applications and IOs are not repeating very often (disk
cache efficiency is probably very low).
Any idea why the kernel behaves like this and how I can get expected
behaviour? Expected behaviour for a desktop would be:
Use as much disk cache as there is free RAM. Once applications start using all
the ram, only keep a certain percentage/bare minimum of disk cache. What is
absolutely undesirable is a growing and growing disk cache when there is not
enough ram to keep applications and/or their data in ram.
> If this tries so hard to avoid swap that you get an out-of-memory condition
> you may also have to disable the hard maplimit with this:
> echo 0 > /proc/sys/vm/hardmaplimit
Yes I get oom conditions with mapped=100 but they are not my real problem, the
problem is the disk cache usage pattern. I it would help, I still have some
dmesg output from the oom killer.
Any ideas? Am I just doing something wrong? I don't use any
special /proc-settings other than the swappiness/mapped test values.
Alex
prev parent reply other threads:[~2005-06-20 19:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-14 14:53 Swapping in 2.6.10 and 2.6.11.11 on a desktop system Alexander Gretencord
2005-06-14 16:42 ` Con Kolivas
2005-06-15 13:44 ` Alexander Gretencord
2005-06-16 4:16 ` Con Kolivas
2005-06-20 19:09 ` Alexander Gretencord [this message]
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=200506202109.51059.arutha@gmx.de \
--to=arutha@gmx.de \
--cc=kernel@kolivas.org \
--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