Re: page_launder() on 2.4.9/10 issue

[Andrea Arcangeli <andrea@suse.de>]

On Tue, Sep 04, 2001 at 10:10:42PM +0200, Daniel Phillips wrote:
> Which reproducible deadlocks did you have in mind, and how do I reproduce
> them?

I meant the various known oom deadlocks. I've one showstopper report
with the blkdev in pagecache patch with in use also a small ramdisk
pagecache backed, the pagecache backed works like ramfs etc.. marks the
page dirty again in writepage, somebody must have broken page_launder or
something else in the memory managment because exactly the same code was
working fine in 2.4.7. Now it probably loops or breaks totally when
somebody marks the page dirty again, but the vm problems are much much
wider, starting from the kswapd loop on gfp dma or gfp normal, the
overkill swapping when there's tons of ram in freeable cache and you are
taking advantage of the cache, lack of defragmentation, lack of
knowledge of the classzone to balance in the memory balancing (this in
turn is why kswapd goes mad),  very imprecise estimation of the freeable
ram, overkill code in the allocator (the limit stuff is senseless), tons
magic numbers that doesn't make any sensible difference, tons of cpu
wasted, performance that decreases at every run of the benchmarks,
etc...

If you believe I'm dreaming just forget about this email, this is my
last email about this until I've finished.

Andrea