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

Yes, editing sysctl.conf is the obvious thing to do.
Reason why I didn't is that there is no sysctl command on my install 
(Familiar 0.8.2) and the .conf doesn't exist either.
I simply assumed the conf would not be read if there is no sysctl binary 
to do it?
Either way we shall see how this works.

M.

June Tate-Gans wrote:
> Actually, just edit /etc/sysctl.conf and add the line:
>
>    vm.overcommit_memory=2
>
> At the bottom, save it, and then issue the following command as root:
>
>    sysctl vm.overcommit_memory=2
>
> And that will set it for the current session. =o)
>
> On 11/7/06, Michael Blatt <[email protected]> wrote:
>> 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
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>
>