> >> 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.
> I'm currently investigating the old non-overcommit patch, which (apart from
> needing manual applying to recent kernels) appears to be rather broken in a
> trivial way. It prevents allocation if total reserved memory is greater
> than the total unallocated memory. Let me say that again, a different way
> - it prevents memory usage from exceeding 50%...
> Is there a fast way of getting total VM size? Eg. equivalent to the
> following code:
> free = i.totalram + i.totalswap;
Other than using their components?.. don't know.
> If not, I have to do some jiggery to keep good performance along with true
(thinking about mlock and what that could do to any saved state.. and
how long allocations can block and where.. egad. then there's zones)
I'm no VM expert, but I wonder if the overhead of obtaining this info
will be the worst you have to deal with.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/