From: Bill Davidsen <davidsen@tmr.com>
To: Charles Shannon Hendrix <shannon@widomaker.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: OOM kills if swappiness set to 0, swap storms otherwise
Date: Wed, 05 Apr 2006 16:47:30 -0400 [thread overview]
Message-ID: <44342CE2.208@tmr.com> (raw)
In-Reply-To: <20060405144716.GA10353@widomaker.com>
Charles Shannon Hendrix wrote:
> Mon, 27 Mar 2006 @ 19:59 -0800, Andrew Morton said:
>
>> Much porkiness.
>>
>> /proc/meminfo is very useful for obtaining a top-level view of where all
>> the memory's gone to. I'd tentatively say that your options are to put up
>> with the swapping or find a new mail client.
>
> I use mutt for my email, and I have the same issue on a 1GB system.
>
> I really wish we could put an upper limit on what file cache can use.
>
> I understand the original poster was running a lot of pork, but you
> don't have to and still see a problem with swapping. Even running KDE
> my total application memory most of the time is 300MB or less on a
> machine with 1GB of memory.
>
> I shouldn't be suffering from swap storms.
Agreed, does meminfo show that you are? The reason I ask is that I have
noted that large memory machines and CD/DVD image writing suffer from
some interesting disk write patterns. The image being built gets cached
but not written, then the file is closed. At some point the kernel
notices several GB of old unwritten data and decides to write it. This
makes everything pretty slow for a while, even if you have 100MB/s disk
system.
>
> For example, my normal working set of programs eats about 250MB of memory. If
> I also start a job running to something like tag some mp3s, copy a CD, or just
> process a lot of files, it only takes a few minutes before performance becomes
> unacceptable.
In theory you should be able to tune this, but in practice I see what
you do. On small memory machines it's less noticable, oddly.
>
> If you are doing some work where you switch among several applications
> frequently, the pigginess of file cache becomes a serious problem.
>
> Isn't that bad behavior by any measure?
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
next prev parent reply other threads:[~2006-04-05 21:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-28 1:53 OOM kills if swappiness set to 0, swap storms otherwise Lee Revell
2006-03-28 3:59 ` Andrew Morton
2006-03-28 4:09 ` Lee Revell
2006-03-28 4:12 ` Parag Warudkar
2006-03-28 4:20 ` Lee Revell
2006-04-05 14:47 ` Charles Shannon Hendrix
2006-04-05 20:47 ` Bill Davidsen [this message]
2006-05-02 4:12 ` Charles Shannon Hendrix
2006-04-11 8:33 ` Linda Walsh
2006-05-02 4:21 ` Charles Shannon Hendrix
2006-05-02 5:04 ` Randy.Dunlap
2006-03-28 11:41 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2006-04-06 1:13 Shantanu Goel
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=44342CE2.208@tmr.com \
--to=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shannon@widomaker.com \
/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