From owner-freebsd-hackers Wed Feb 28 15: 8:45 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 4700437B718 for ; Wed, 28 Feb 2001 15:08:43 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1SN8hC93566; Wed, 28 Feb 2001 15:08:43 -0800 (PST) (envelope-from dillon) Date: Wed, 28 Feb 2001 15:08:43 -0800 (PST) From: Matt Dillon Message-Id: <200102282308.f1SN8hC93566@earth.backplane.com> To: Peter Dufault , hackers@FreeBSD.ORG Subject: Re: memorylocked resource (was "Setting memory allocators...") References: <200102281332.f1SDWPD27689@hda.hda.com> <200102282249.f1SMn6N93107@earth.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ::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, Heh heh. I didn't answer that very well the first time eh? In regards to mlockall(MCL_FUTURE). Hmm. Well, you could certainly implement it inside vm_fault but there are a couple of other cases where the system manually enters a page into the user's page table. I haven't researched it but I would not expect it to be difficult. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message