Date: Fri, 22 Jan 1999 18:31:58 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: dyson@iquest.net, hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change Message-ID: <199901222331.SAA22095@hda.hda.com> In-Reply-To: <199901221953.LAA56414@apollo.backplane.com> from Matthew Dillon at "Jan 22, 99 11:53:25 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> Basically what it comes down to is that I do not think it is appropriate > for there to be hacks all around the kernel to arbitrarily block processes > in low memory situations. At the very worst, those same 'blockages' could > be implemented in one place - the memory allocator, and nowhere else. But > we can do much better. No one will argue with that. While moving things to one place you should define requirements also so that you can see that changes don't break anything. As someone interested in realtime I'll toss two requirements at you: you should be able to behave as if you have less physical memory than you do to permit locked in regions (should be easy), and your algorithms should be able to define a maximum amount of time (for a specific configuration) that it will take to reduce that number, that is, if I give you five seconds warning can you guarantee me more two more MB memory? For the second requirement don't concern yourself with obvious Unixy issues or anything outside the VM subsystem, only that the algorithms in your now well contained subsystem are determinate. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical 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?199901222331.SAA22095>