From owner-freebsd-arch  Tue Nov  7 14: 4:48 2000
Delivered-To: freebsd-arch@freebsd.org
Received: from implode.root.com (root.com [209.102.106.178])
	by hub.freebsd.org (Postfix) with ESMTP id CF7D337B479
	for <arch@FreeBSD.ORG>; Tue,  7 Nov 2000 14:04:45 -0800 (PST)
Received: from implode.root.com (localhost [127.0.0.1])
	by implode.root.com (8.8.8/8.8.5) with ESMTP id OAA00682;
	Tue, 7 Nov 2000 14:04:00 -0800 (PST)
Message-Id: <200011072204.OAA00682@implode.root.com>
To: Julian Elischer <julian@elischer.org>
Cc: arch@FreeBSD.ORG
Subject: Re: softdep panic due to blocked malloc (with traceback) 
In-reply-to: Your message of "Tue, 07 Nov 2000 13:21:27 PST."
             <3A087257.DBA40791@elischer.org> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Tue, 07 Nov 2000 14:04:00 -0800
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>>         I think both Matt's changes and what Poul-Henning can be useful.
>> (Actually, it sounds like Matt's are required, and Poul-Henning's might be
>> nice if and when someone does them).
>
>I think that they are talking with cross purposes..
>
>Matt is right that nothing that magically comes up with a few hundred KB
>of ram
>can be guaranteed to stop a deadlock, because after the few hundred KB
>have been
>used up, If the big memory hog keeps eating memory, you are right back
>where you 
>started, and you no longer have a few hundred KB up your sleeve. 
>
>On the other hand, PHK is correct in that it would be a useful facility
>to have and that it might buy some breathing space. To be ueful however
>I think it 
>would need to be combined with some other measures to ensure that we
>don't get straight 
>back into debt. For example triggering that queue might change the
>strategies in the 
>kernel so that the biggest memory users are forced to start losing
>pages. 
>(e.g. it's swapped out) or some similar work.. 

   The problem with this line of thinking is that transient memory shortages
happen all the time in normal operation of the system and one definately
doesn't want to be flushing the cache in these cases - that just makes the
system slower and even less responsive. I really think that cache flushing
is a non-starter solution for any problem (other than cache coherency issues).

-DG

David Greenman
Co-founder, The FreeBSD Project - http://www.freebsd.org
President, TeraSolutions, Inc. - http://www.terasolutions.com
Pave the road of life with opportunities.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message