Date: Wed, 28 Feb 2001 08:31:49 -0500 (EST) From: Peter Dufault <dufault@hda.hda.com> To: hackers@freebsd.org Subject: memorylocked resource (was "Setting memory allocators...") Message-ID: <200102281332.f1SDWPD27689@hda.hda.com>
next in thread | raw e-mail | index | archive | help
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, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102281332.f1SDWPD27689>