Re: Ongoing 2.4 VM suckage

[Jeremy Linton]

From: "Stephen Satchell" <[e-mail]>
> At 07:08 PM 8/3/01 -0300, you wrote:
> >On Fri, 3 Aug 2001, Mike Black wrote:
> >
> > > Couldn't kswapd just gracefully back-off when it doesn't make any
> > > progress? In my case (with ext3/raid5 and a tiobench test) kswapd
> > > NEVER actually swaps anything out. It just chews CPU time.
> >
> > > So...if kswapd just said "didn't make any progress...*2 last sleep" so
> > > it would degrade itself.
> >
> >It wouldn't just degrade itself.
> >
> >It would also prevent other programs in the system
> >from allocating memory, effectively halting anybody
> >wanting to allocate memory.
Big snip...

> To the rest of the kernel list:  apologies for taking up so much space
with
> a userland issue.  The thing is, in the months I've seen the VM problem
> discussed, and the "zillionth person to complain about it," I haven't seen
> any pointer to any discussion about how userland programs can insulate
> themselves from being killed when they try to use up too much
> RAM.  Commercial quality programs, and programs wanting to use as much of
> the resources as possible to minimize run times, need to monitor what they
> are doing to the system and pull back when they tread toward suicide.
>
> Put another way, people should NOT use safety nets as the only means of
> breaking a fall.
    AIX, also allows something similar to linux's over commit. Right before
its OOM killer fires it sends the target process(es) a non standard signal
(can't remember what its called) which indicates that if the process
continues to allocate memory it runs the risk of being killed.

I'm not advocating this idea, only presenting it as a solution other people
have implemented to work around broken VM issues.

    jlinton