On September 5, 2001 12:04 am, Andrea Arcangeli wrote:
> 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.
Sure. You mentioned one deadlock - oom - and a bunch of suckages. The oom
problem is related to imprecise knowledge of freeable memory, you could group
those two together. Active defragmentation isn't going to be that hard, I
think. We'll see...
Don't forget all the stuff that works pretty well now. Most of the problem
reports we're getting now are concerned with the fact that we're loading up
logs with allocation failure messages. We probably wouldn't get those
reports if we just turned of the messages now. Bounce buffer allocation was
the stopper there and Marcelo's patch has put that one away. I think I found
a practical solution to the 0 order atomic failures, subject to more
confirmation. Balancing and aging, while not perfect, are at least
servicable. Hugh Dickins rooted out a bunch of genuine bugs in swap. Rik
seems to have defanged the swap space allocation problem. Other bugs were
rooted out and killed by Ben and Linus. All in all, things are much improved.
The biggest issue we need to tackle before calling it a servicable vm system
is the freeable memory accounting.
-- Daniel - 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 : Fri Sep 07 2001 - 21:00:29 EST