"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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 07 2003 - 22:00:20 EST