From owner-freebsd-arch Tue Nov 7 14:20: 3 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 ED79637B479 for ; Tue, 7 Nov 2000 14:19:59 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA7MI5w83049; Tue, 7 Nov 2000 14:18:05 -0800 (PST) (envelope-from dillon) Date: Tue, 7 Nov 2000 14:18:05 -0800 (PST) From: Matt Dillon Message-Id: <200011072218.eA7MI5w83049@earth.backplane.com> To: David Greenman Cc: Poul-Henning Kamp , Bruce Evans , Kirk McKusick , arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) References: <200011072159.NAA00641@implode.root.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok guys... I'll apologize here for tying these two things together. I really thought Poul was talking about his idea in the context of an extreme low-memory situation. That said, however, I must still disagree with the concept. I think KVM needs to be managed actively, not randomly from third party routine(s) deciding they wants 'general' KVM subsystems to clear out some memory. For example, take the vnode/inode cache ... the only subsystem that really knows how to manage the vnode/inode cache is the vnode/inode subsystem. If it doesn't know how to manage the cache, then certainly no third party routine outside that subsystem which decides to call the cleanup chain will know! Even if taken only as a hint, its a hint given by a third party routine which has no clue about the vnode/inode cache or any other cache. It's a worthless hint. There is no such thing as 'potential breathing room' in an extreme low-memory situation. There is only what you can guarentee, and the only thing you can guarentee is managed control over the last vm.v_free_reserved pages of memory. You guarentee the managed control by guarenteeing that the only subsystems allowed to allocate from that pool know how to release their resources in real time (allocate, perform function, release) when faced with extreme low-memory situations. The memhog3.c program, for example, can allocate and DIRTY *hundreds* of megabytes in less then a second. Hundreds! No cleanup chain could ever hope to compete against that. Perhaps what we really need is some sort of wakeup chain, something that runs once a second or 5 times a second or something like that which could call a chain of management routines every so often (rather then having to create kernel threads which sleep on lbolt for each subsystem). These cleanup routines would be charged with the duty of maintaining their respective caches, *not* flushing them, and would not be allowed to block. Maintainance rather then flushing... I think something like that could be beneficial. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message