Locking kdecore into memory

[Gary L. Greene, Jr.]

On Tuesday 23 January 2007 14:02, Krzysztof Lichota wrote:
> 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.

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.

> 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

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

[1] Web-browsing with either Konqueror or Firefox with multiple tabs, PIM 
using Kontact, watching movies or listening to music using Kaffeine, etc. 
(I'm not counting OO.org usage or compilation of software, since they bloat 
numbers more than a little.)

-- 
Gary L. Greene, Jr.
Sent from: uriel.tolharadys.net
 15:21:56 up 1 day, 22:40,  5 users,  load average: 0.01, 0.12, 0.15
=========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
 See www.tolharadys.net and www.kde.org for more information
=========================================================================

Please avoid sending me Word or PowerPoint attachments.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070123/bb0eb446/attachment.sig>