From owner-freebsd-hackers Fri Jan 22 15:54:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA04443 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 15:54:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA04436 for ; Fri, 22 Jan 1999 15:54:56 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 9943 invoked from network); 22 Jan 1999 23:54:43 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 22 Jan 1999 23:54:43 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id SAA36875; Fri, 22 Jan 1999 18:54:44 -0500 (EST) Message-Id: <199901222354.SAA36875@y.dyson.net> Subject: Re: Error in vm_fault change In-Reply-To: <199901222331.SAA22095@hda.hda.com> from Peter Dufault at "Jan 22, 99 06:31:58 pm" To: dufault@hda.com (Peter Dufault) Date: Fri, 22 Jan 1999 18:54:44 -0500 (EST) Cc: dillon@apollo.backplane.com, dyson@iquest.net, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (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 Peter Dufault said: > > 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. > Your comments about "goals" are correct. The obsolete notion of priority is specious. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message