From owner-freebsd-hackers Wed Feb 28 14:49:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 69B3B37B71F for ; Wed, 28 Feb 2001 14:49:18 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1SMn6N93107; Wed, 28 Feb 2001 14:49:06 -0800 (PST) (envelope-from dillon) Date: Wed, 28 Feb 2001 14:49:06 -0800 (PST) From: Matt Dillon Message-Id: <200102282249.f1SMn6N93107@earth.backplane.com> To: Peter Dufault Cc: hackers@FreeBSD.ORG Subject: Re: memorylocked resource (was "Setting memory allocators...") References: <200102281332.f1SDWPD27689@hda.hda.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hmm. Well, mlock() is one of those system calls that virtually nobody has worked on since inception. The most I've done with it has been to fix bugs. The resource issues for mlock() aren't really good enough to prevent misuse in a general multiuser system. The resource is per-process rather then per-user, and in fact not even implemented. And the locked memory is not advisory so there is no way for the kernel to recover it under heavy load conditions until the process releases it or exits. If you grep for RLIMIT_MEMLOCK you find a minimal implementation of the resource limit in vm/vm_mmap.c. 'pmap_wired_count' is not defined, so the implementation is to be root-only and to ignore the resource limit. Even with pmap_wired_count implemented the implementation is per-process, which is not sufficient protection. -Matt :Why is the mlock(2) call restricted to the super user instead :of enforcing it through per-user or per-login class limits? :I was checking to see if most of the pieces were in place for :"mlockall(MCL_FUTURE)" and noticed the "memorylocked infinity" :setting in limits (I didn't know about memorylocked). Setting :"memorylocked 0" for normal users is a flexible way to address :this, then create a special class of programs that are permitted :to do some locking. : :Along the same lines (matt probably knows the answer) is it :easy to force paging in and locking down of any memory associated :with a process so that mlockall(MCL_FUTURE) together with :an appropriate memorylocked limit gives the requested :memory semantics? I'd have to check through the specs to see :how mmap() is supposed to play with mlockall(). : :Please leave aside most resource management issues :for now, I'm assuming the main use for this is debugged :small closed embedded systems, only bring up kickers. : :Peter : :-- :Peter Dufault (dufault@hda.com) Realtime development, Machine control, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message