Locking kdecore into memory

[Krzysztof Lichota]

Gary L. Greene, Jr. napisał(a):
>> I am not sure locking only part of necessary pages would be much benefit
>> as they are all necessary to keep GUI running. It is all or nothing
>> thing, IMO. Either you have enough memory to afford pinning some of it
>> for sake of GUI responsiveness, or you don't have much memory and it
>> does not make sense as other programs might need the memory.
> 
> Exactly. The point IMO of working around this is mainly to be sure that there 
> will always be the ability to bring up the task manager, so _you_ not the 
> kernel can kill the errant process that is eating your machine alive. Leaving 
> it to the OOM killer is not something that end users will be too pleased 
> with.

OOM killer is run when system runs out of virtual memory, so running
task manager in such condition would be really difficult - we would have
to ensure it is not allocating any new memory by itself and indirectly
(for example in X server). It is really hard and I think latest patch
changing oom priority solves this problem, so it is not necessary.

Pinning pages of GUI would improve responsiveness in case some process
is eating a lot of memory or processes are swapped out for different
reason (for example they are idle for long time).

>> So maybe locking these used pages instead of locking whole libraries
>> would be helpful and not too resource intensive. Proper kernel module
>> should do the trick, no need to raise mlock limits for all processes :)
> 
> From what I've noted, the total that would need locked would be around 20 to 
> 30MB. This isn't much on most hardware that exists. 

I would estimate it in the same range, though I didn't make any real
tests :)

> For those that have only 
> 128 MB of RAM, I'd recommend that they move up to at least 256MB, since 
> overall performance with the normal set of kernel daemons, system processes, 
> X, and typical KDE usage[1] comes in between 212 and 240MB of RAM with the 
> empirical testing I've done. All post 2000 hardware can handle 256MB without 
> issue, and would be fairly cheap to get the added RAM.

I think we should not enforce people to change their hardware. Sometimes
it is hard, sometimes impossible. We should handle low-end hardware
gracefully.

	Krzysztof Lichota


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070124/d2ff449d/attachment.sig>