From: Andrew Morton <akpm@osdl.org>
To: "Scott L. Burson" <gyro@zeta-soft.com>
Cc: linux-kernel@vger.kernel.org, Mathieu.Malaterre@creatis.insa-lyon.fr
Subject: Re: SMP performance problem in 2.4 (was: Athlon spinlock performance)
Date: Sat, 2 Aug 2003 14:44:22 -0700 [thread overview]
Message-ID: <20030802144422.111d6893.akpm@osdl.org> (raw)
In-Reply-To: <16171.31418.271319.316382@kali.zeta-soft.com>
"Scott L. Burson" <gyro@zeta-soft.com> wrote:
>
> The problem is in `try_to_free_pages' and its associated routines,
This is not unusual.
> In one approximately 60-second period with the problematic workload running,
What is the problematic workload? Please describe it in great detail.
> Clearly the kernel group has been aware of the problems with `shrink_cache',
> as I see that it has received quite a bit of attention in the course of 2.5
> development. I am hopeful that the problem will be substantially
> ameliorated in 2.6.0. (The comment at the top of `try_to_free_pages' --
> "This is a fairly lame algorithm - it can result in excessive CPU burning"
> -- suggests it won't be cured entirely.)
That comment has thus far proved to be wrong.
> However, it seems the kernel group may not have been aware of just how bad
> the problem can be in recent 2.4 kernels on dual-processor machines with
> lots of memory. It's bad enough that running two `find' jobs at the same
> time on large filesystems can bring the machine pretty much to its knees.
oh, is that the workload?
Send a copy of /proc/meminfo, captured when the badness is happening. Also
/proc/slabinfo.
Probably you will find that all of the low memory is consumed by inodes and
dentries. ext2 is particularly prone to this because its directory pages
are placed in highmem, and those pages can pin down the dentries (and hence
the inodes).
So sigh. It is a problem which has been solved for a year at least. Try
running one of Andrea's kernels, from
ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4
The most important patch for you is 10_inode-highmem-2.
next prev parent reply other threads:[~2003-08-02 21:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-02 20:03 Scott L. Burson
2003-08-02 21:44 ` Andrew Morton [this message]
2003-08-03 10:00 ` Scott L. Burson
2003-08-06 2:37 ` Rik van Riel
2003-08-03 2:40 ` Rik van Riel
2003-08-03 5:18 ` Con Kolivas
2003-08-06 17:21 Manfred Spraul
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=20030802144422.111d6893.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=Mathieu.Malaterre@creatis.insa-lyon.fr \
--cc=gyro@zeta-soft.com \
--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®