Locking kdecore into memory

[subbukk]

On Tuesday 23 January 2007 21:59, Gary L. Greene, Jr. wrote:
> Subbu, there is a little fallacy in your logic here. Lubos _has_ talked
> with Kernel hackers about getting the OOM fixed, and they plain aren't
> interested in fixing it as stated by him before on this list.
With all due respect to Lubos, I submit that allowing non-root apps to pin 
down precious memory is not the way to go about achieving graceful 
degradation under OOM. This will only worsen the problem. OOM is an 
emergency situation (like low battery). Current Linux OOM handling seems 
biased towards server loads and may not suit interactive desktop 
sessions. But then there is no clear cut case to let X or KDE hog RAM 
over, say, a background compilation job.
> .. I've
> had several cases where my system started spinning its wheels and
> locking up the UI so badly, that I couldn't use the system, let alone
> kill the processes, and had to restart X11 and KDE when the OOM killer
> killed X instead of the process that actually was the culprit
> (incidentally, building OO.org is one of the culprits with having only
> 512MB of RAM installed on a system....)
I too faced freezes/blowuups when trying to build KDE on a 256MB Celeron 
notebook (!). What really upset me in those incidents is the lack of any 
warning before OOM. But once I realized that OOM was the issue, I could 
understand that my box was underpowered for such workloads. I shutoff X, 
scheduled my jobs and restarted X when the compilation was done. I could 
use a coffee break :-).

Should we step back and look at the larger picture for a proper solution? 
Should KDE run a tiny background daemon that monitors system resources 
(memory, battery, disk space) for dangerous limits and blink a warning, 
so the UI freeze is not a nasty surprize?

Subbu