Locking kdecore into memory

[Stefan Teleman]

On Sunday 21 January 2007 17:25, Richard Moore wrote:
> On 1/21/07, Lubos Lunak <l.lunak at suse.cz> wrote:
>
> So we have some sort of kdeinit like process that runs setuid and
> calls mlockall()? That would be able to lock the libraries into ram
> I guess. To be useful though, how much would we have to lock?
> kdecore, kdelibs, qt, X11 and libc I guess. That's quite a bit.

A lot. :-)

> > > You
> > > can also get bitten by the fact that if two processes lock a
> > > page, and one unlocks it the page gets unlocked - there is no
> > > ref count.
> >
> >  I don't think there'd be any unlocking.

On Solaris (at least) refcounting is done both process- and 
system-wide -- i.e. if the same process keeps locking the same page, 
one munlock() will unlock it within that process, even though the 
page has been locked more than once (in other words, within the same 
process address space, mlock() is not additive).  If the same page is 
locked by two or more different processes, munlock()'ing it in one 
process will not munlock() it in another process.

> That means we need to do this on a system wide basis, otherwise you
> wouldn't be able to run multiple sessions. I guess it could be
> argued though that there's still a net win as the behaviour would
> merely return to what we have now.

For S8 and S9, mlock()/munlock() needed root privileges. In S10, the 
user needs PRIV_PROC_LOCK_MEMORY privilege, which does not imply 
root. The caution here is that in some "corporate" environments, such 
a privilege is not granted (once a user get such a privilege, then 
the same user can write and run a program which keeps locking pages 
in memory, unrelated to KDE, and the sysadmins will have a heart 
attack at this idea :-).

My only question here is: what are the tradeoffs between benefits and 
adverse effects ? In my experience, using mlock()/munlock() were 
generally reserved for programs which could not tolerate the overhead 
of page faults (i.e. real-time systems), and were not used as a 
preventive measure ... i am particularily thinking about the 
potential side-effects of mlock()'ing libc.so ...

--Stefan

-- 
Stefan Teleman			'Nobody Expects the Spanish Inquisition'
KDE e.V.						-Monty Python
stefan.teleman at gmail.com