Re: freezes...

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