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

Actually, reading man 5 proc reveals this:

In mode 0, calls of  *mmap(2) <http://www.tin.org/bin/man.cgi?section=2&topic=mmap>*  with  MAP_NORESERVE  set  are  not
checked, and the default check is very weak, leading to the risk
of getting a process "OOM-killed".  Under Linux 2.4 any  nonzero
value  implies  mode  1.  In mode 2 (available since Linux 2.6),
the total virtual address space on the system is limited to  (SS
+  RAM*(r/100)), where SS is the size of the swap space, and RAM
is the size of the physical memory, and r is the contents of the
file //proc/sys/vm/overcommit/*_*/ratio/.

So setting it to 2 would be useless in this case since we are not on kernel 2.6, or have I missed something?
:-/

Shame that power management is still a problem in 2.6...
Kristoffer, since you are playing with 2.6 on the J720, maybe you can confirm whether touchscreen and PM work?
That has held me off using it for myself. 

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