From owner-freebsd-arch Tue Nov 7 11:25:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 0448B37B4C5 for ; Tue, 7 Nov 2000 11:25:28 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA7JNN881648; Tue, 7 Nov 2000 11:23:23 -0800 (PST) (envelope-from dillon) Date: Tue, 7 Nov 2000 11:23:23 -0800 (PST) From: Matt Dillon Message-Id: <200011071923.eA7JNN881648@earth.backplane.com> To: Poul-Henning Kamp Cc: Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) References: <25669.973620773@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Could we please have an eventhandler chain which gets called when :we are short of KVM ? There are code which can free KVM with no :significant loss of anything but performance, if only we bother to :tell it to do so. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :phk@FreeBSD.ORG | TCP/IP since RFC 956 I don't think garbage collection is the answer, because there is always the possibility that there may not be sufficient garbage to collect. Resources have to be managed more actively and in such a way as to allow the system to recover from a severe memory shortage. What this comes down to is that the I/O chain needs to be able to operate 'continuously' in a restricted memory environment. Accomplishing this is extremely easy for the I/O chain -- one simply does not do any delayed-writes and one simply returns resources when one is through with them rather then trying to cache them. As long as the I/O chain continues to operate, the rest of the system can block, and recover, without creating a deadlock situation. It could be argued that garbage collection has already been tried and found to be wanting. The pmap subsystem tries to garbage-collect page table pages already, and the results are not encouraging at all - it's a performance headache plus it cannot guarentee that anything will be returned to the system anyway. In fact, in low-memory situations the pmap garbage collection doesn't help the pagedaemon at all. It frees up some pages and the system then proceeds to eat those up and run out of memory again. The system will still run out of memory. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message