Locking kdecore into memory

Krzysztof Lichota krzysiek at lichota.net
Tue Jan 23 19:02:59 GMT 2007

Leo Savernik napisaƂ(a):
> Am Dienstag, 23. Januar 2007 19:17 schrieb Lubos Lunak:
>>> On my backup machine with 128MB it is a lot!
>>> Not everyone has the latest-fastest-coolest machine. In fact, kde 3 is
>>> running nicely on my backup machine. Shall we really go the Vista way and
>>> assume the user has always the latest hardware?
>>  No. I suggest going the normal way and assuming the presence of a brain in
>> the skull.
> I suggest autodetecting the total amount of ram and scale linearly. No need to 
> occupy a brain if it can be done by a computer program.

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.

But the working set might not be that large - as far as I have seen in
/proc/xxx/smaps, only small parts of libraries are used in normal
operation, most are used only during initialization and in special
cases. For example, for Konqueror:
r-xp 00000000 03:01 249127     /usr/lib/libqt-mt.so.3.3.6
Size:              7804 kB
Rss:               2160 kB
Shared_Clean:      2160 kB
Shared_Dirty:         0 kB
Private_Clean:        0 kB
Private_Dirty:        0 kB

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

My 2c

	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/20070123/dabf8c9c/attachment.sig>

More information about the kde-core-devel mailing list