From owner-freebsd-hackers Mon Feb 26 9:57: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 10E5A37B401 for ; Mon, 26 Feb 2001 09:57:01 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f1QHsma18433; Mon, 26 Feb 2001 12:54:48 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200102261754.f1QHsma18433@hda.hda.com> Subject: Re: Setting memory allocators for library functions. In-Reply-To: <3A99F25A.B940BEE0@elischer.org> from Julian Elischer at "Feb 25, 2001 10:06:18 pm" To: Julian Elischer Date: Mon, 26 Feb 2001 12:54:44 -0500 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I still think that in such a case it should be possible to > 'test the commitment' by touching all the allocated memory > while trapping page faults. and fault all your memory from > 'potential' to 'allocated'. As someone said. it is not sure which program > when you run out of swap, but I think you might be able to somehow > change this behaviour to "the program making the request" fails > (or gets a fault). > > You could allocate your memory. > trap faults. > touch all of the allocated memory. > if it faults, you can remap some file to that location to allow the > instruction to continue.. continue and abort the check.. > exit as needed, OR continue with secure knowledge that > all your memory is there. > Alternatively you could allocate your own on-disk swapspace for > a program by telling malloc to use a file for all your memory needs. I think the right way to implement this would be define a POSIX P1003.1 "mlockall(MCL_CURRENT|MCL_FUTURE)" along with a physical memory limit resource. I think this could be defined to give the requested malloc performance. This is defined to be not inherited so you'd still need to modify your program. I absolutely agree this is a can of worms, but this would be a way to proceed. 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