Date: Tue, 7 Nov 2000 11:41:35 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Bruce Evans <bde@zeta.org.au>, Kirk McKusick <mckusick@mckusick.com>, arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) Message-ID: <200011071941.eA7JfZX81819@earth.backplane.com> References: <26296.973625216@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
:We are not talking garbage collection, we are talking dumping the :vfs namecache for instance. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 Yes, but think a minute: How does that prevent a low memory deadlock? The answer is not "because it frees up some pages" ... what if you've already freed up all the namecache pages you can and some process continues to eat memory, and now you have none left to free? The issue is how to avoid a memory deadlock. The problem with freeing cache resources is that it doesn't help you avoid a memory deadlock. If someone immediately reallocates the memory for another purpose -- and dirties it so it can't be freed again. To avoid a memory deadlock you have to manage the processes doing the allocations during the low-memory situation, not the people who already have it in caches. In the case of the I/O subsystem, this management takes the form: The I/O system must be able to work in a low-memory situation, so we manage it by immediately freeing (recycling) resources used in the I/O during the low-memory situation rather then blocking the I/O. Because the I/O subsystem is now well behaved, we can allow it to eat into the system memory reserve because we know it will not exhaust the reserve. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011071941.eA7JfZX81819>