Re: VM nuisance

David Ford (david@blue-labs.org)
Sat, 11 Aug 2001 11:39:52 -0400


Alan Cox wrote:

>>Followup to: <Pine.LNX.4.33L.0108102347050.3530-100000@imladris.rielhome.conectiva>
>>By author: Rik van Riel <riel@conectiva.com.br>
>>In newsgroup: linux.dev.kernel
>>
>>>I haven't got the faintest idea how to come up with an OOM
>>>killer which does the right thing for everybody.
>>>
>>Basically because there is no such thing?
>>
>
>And also because
>
>- people mix OOM and thrashing handling up - when they are logically
> seperated questions.
>

I understand this, I use reiserfs and because of this there is an
increased baseline for "no more memory". This leads to your last
paragraph below. The problem is that the OOM handler hasn't been made
aware of this.

Don't we already measure VM pressure? It may be a hack but we could
adjust the triggerpoint of the OOM handler on a sliding scale
proportionate to the VM pressure, could we not? I think that is the
most simple hack until we have a decent resource baseline in place..each
subsystem would keep a tally of how much required memory it had/wanted
and that way, the OOM handle would be much more intelligent about when
to fire.

So this posits two questions.

- How hard/how much time.. is a sliding pressure scale hack to implement

- How hard/how much time.. to implement resource baselines (or similar
concept)

David

>- The 2.4 VM goes completely gaga under high load. Its beautiful under
> light loads, there nobody can touch it, but when you actually really
> need it - splat.
>
>
>So people either need to get an OOM when they are not but in fact might
>thrash, or the box thrashes so hard it makes insufficient progress to
>actually get out of memory.
>
>OOM is also very hard to get right without reservations tracking in kernel
>for the journalling file systems and other similar stuff. To an extent
>thrash handling also wants RSS limits.
>

-
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/