Date: Mon, 26 Feb 2001 12:54:44 -0500 (EST) From: Peter Dufault <dufault@hda.hda.com> To: Julian Elischer <julian@elischer.org> Cc: hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. Message-ID: <200102261754.f1QHsma18433@hda.hda.com> In-Reply-To: <3A99F25A.B940BEE0@elischer.org> from Julian Elischer at "Feb 25, 2001 10:06:18 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102261754.f1QHsma18433>