> >> While my post didn't give an exact formula, I was quite clear on the
> >>fact that
> >> the system is allowing the caches to overrun memory and cause oom problems.
> >
> >Yes. A testcase would be good. It's not happening to everybody nor is
> >it happening under all loads. (if it were, it'd be long dead)
> >
> >> I'm more than happy to test patches, and I would even be willing to suggest
> >> some algorithms that might help, but I don't know where to stick them in the
> >> code. Most of the people who have been griping are in a similar position.
> >
> >First step toward killing the critter is to lure him onto open ground.
> >Once there.. well, I've seen some pretty fancy shooting on this list.
>
> My patch already fixes OOM problems caused by overgrown caches/buffers, by
> making sure OOM is not triggered until these buffers have been cannibalised
> down to freepages.high. If balancing problems still exist, then they
> should be retuned with my patch (or something very like it) in hand, to
> separate one problem from the other. AFAIK, balancing should now be a
> performance issue rather than a stability issue.
Great. I haven't seen your patch yet as my gateway ate it's very last
disk. I look forward to reading it.
-Mike
-
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/