Re: freezes... (aka. taming the OOM killer)

Further on this topic. I spent a few minutes looking around for the 
sysctl command on my J720, but this does it:

 echo 2 > /proc/sys/vm/overcommit_memory

Obviously to survive a reboot this will need to go into an init script 
or other.

Michael


Michael Blatt wrote:
> I suspected the OOM killer in 2.4 wasn't the smartest bit in the 
> kernel :)
> Very clever trick, I should have thought about looking at possible 
> sysctls.
> In fact I'm going to set it now (remotely) and check it out tonight.
> The thing about the qpf fonts I need to check though. I think my fonts 
> are only qpf, but we shall see.
> Keep us posted on how things are on your side after trying that tweak, 
> I shall do likewise.
>
> Michael
>
> June Tate-Gans wrote:
>> Unfortunately the OOM killer in v2.4 of the Linux Kernel isn't exactly
>> /intelligent/. Generally it tries to kill off the "least active" or
>> "lowest priority" process first, and then moves down the line to the
>> one with the largest consumption of memory at that moment.
>> Unfortunately, Konq/E, OPIE, and ipkg are  (relatively) heavy in terms
>> of resource usage (espeically ipkg -- it's a shell script that forks
>> out to quite a few sub-processes just to function).
>>
>> I have the same issue when I'm running kdrive X, ion3, minimo, rxvt,
>> bash, and apt-get. Interestingly enough, if kdrive is killed off with
>> the OOM, the Jornada's screen seems to "freeze up" instead of cleaning
>> itself up and returning me to a console.
>>
>> You might look into trying to reduce the amount of RAM that Konq/E
>> uses by reducing the existance of varios BDF and TTF fonts on your
>> disk. From the Konq/E FAQ:
>>
>> "The startup time of Konq/E is very slow when using Qt/Embedded. Is
>> there a hidden turbo-boost configure switch to accelerate it to
>> lightspeed?
>>
>> A lot of time on startup is spend on parsing the available fonts. To
>> optimize this make sure Qt/E only uses the .qpf font files for fonts
>> and no .bdf or .ttf fonts . This will decrease startup time
>> dramatically and reduce memory usage. See the Qt documentation of
>> details about .qpf font files and how to generate them."
>>
>> Also, to reduce the randomness and insanity that the OOM killer is on
>> an embedded device like the Jornada, you might want to set the
>> vm.overcommit_memory sysctl to 2. This has the effect of preventing
>> the Linux kernel from "over allocating" RAM, freaking out when it runs
>> out, and then using the OOM killer to free up memory by randomly
>> killing processes. See <http://lwn.net/Articles/104179/> for more
>> information on this trick. The end result is that instead of the OPIE
>> main process being killed, whichever process is trying to allocate
>> more RAM than is available in the system will kill itself since it
>> won't be able to allocate any more.
>>
>> Much more graceful on an embedded device, IMHO -- and I'm going to try
>> out that tweak this week, myself. =o)
>>
>> On 11/7/06, Michael Blatt <[email protected]> wrote:
>>>
>>>
>>>
>>>
>>> Which makes me think, since we were talking about the amount of RAM 
>>> on the
>>> machine:
>>>
>>> I have a J720 with 32MB RAM, and, well, OPIE and apps do run out of 
>>> memory
>>> on a regular basis.
>>>
>>> All it takes is a konq/e with a blank page, an opie-console and ipkg 
>>> running
>>> at the same time, usually. What happens then, I reckon, is that the 
>>> kernel
>>> decides to kill the qpe/opie main process and the UI freezes 
>>> completely.
>>>
>>> What's the best way of dealing with this, short of pulling the plug and
>>> battery out?
>>>
>>> I can ssh into the box and restart opie almost every time this 
>>> happens, but
>>> that is not always practical (and if I had another keyboard nearby I
>>> wouldn't be using the Jornada at that precise moment, would I?).
>>>
>>> I haven't been able to think of a way to get the display and input 
>>> back to
>>> the console when qpe/opie dies, which would be the lesser evil.
>>>
>>> Anyone with any idea how this could be done, or whether there is an
>>> alternative?
>>>
>>>
>>>
>>> Cheers
>>>
>>>
>>>
>>> Michael
>>> _______________________________________________
>>> jornada mailing list
>>> [email protected]
>>> https://handhelds.org/mailman/listinfo/jornada
>>>
>>>
>>>
>>
>>
>
>