From owner-freebsd-hackers Fri Jan 22 11:53:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA01760 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 11:53:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA01755 for ; Fri, 22 Jan 1999 11:53:42 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id LAA56414; Fri, 22 Jan 1999 11:53:25 -0800 (PST) (envelope-from dillon) Date: Fri, 22 Jan 1999 11:53:25 -0800 (PST) From: Matthew Dillon Message-Id: <199901221953.LAA56414@apollo.backplane.com> To: "John S. Dyson" Cc: hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change References: <199901221749.MAA03968@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. I like your RLIMIT_RSS code, but it isn't enough and I think it is implemented in the wrong place. I believe the correct place to implement the 'memory scheduler' is in vm_page_alloc() and vm_wait(). vm_page_alloc() uses some algorithm X ( which could simply be the RSS check ) to determine whether to return NULL or not for VM_ALLOC_NORMAL or VM_ALLOC_ZERO requests. vm_wait() ould implement the RSS enforcement as well as other sophistication. For example, it could determine that the enforcement is insufficient and start scaling it, or it could determine that the system is thrashing and implement a more sophisticated swap/sleep strategy. We can play with the scheduling and enforcement algorithms much more easily this way, too. What do you say ? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message