Re: mlock(1)

[Lee Revell <rlrevell@joe-job.com>]

On Fri, 2004-09-24 at 16:15, Neil Horman wrote:
> Jeff Garzik wrote:
> > 
> > How feasible is it to create an mlock(1) utility, that would allow 
> > priveleged users to execute a daemon such that none of the memory the 
> > daemon allocates will ever be swapped out?
> > 
> > ntp daemon does mlock(2) internally, for example, but IMHO this is 
> > really a policy decision that could be moved out of the app.
> > 
> > Unfortunately I am VM-ignorant as always ;-)
> > 
> 
> I think it would be pretty easy to do.  Since mlock(2) operates on the 
> calling processes vma tree you'd need an interface to the kernel that 
> let you specify a child process and an address range to lock.  Then in 
> the kernel you'd need to translate the pid into task struct and 
> replicate the functionality of sys_mlock without the assumption that 
> current points to the task that you're modifying.  Sounds like something 
> you could do pretty easy with a proc file in fact.
> 

Is this really a good idea?  I suspect it would be abused.  For example,
people would mlock mozilla or openoffice to keep it from being paged out
overnight when updatedb runs, where the real solution is to fix the
problem with the VM that causes updatedb to force other apps to swap
out. 

Making it harder to use mlock ensures that only apps that REALLY need it
will use it, time-critical stuff like ntpd and jackd.

Lee