Date: Wed, 08 Nov 2000 09:55:16 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Alfred Perlstein <bright@wintelcom.net> Cc: Matt Dillon <dillon@earth.backplane.com>, 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: <30679.973673716@critter> In-Reply-To: Your message of "Wed, 08 Nov 2000 00:51:31 PST." <20001108005130.R5112@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20001108005130.R5112@fw.wintelcom.net>, Alfred Perlstein writes: >* Poul-Henning Kamp <phk@critter.freebsd.dk> [001108 00:46] wrote: >> In message <20001107152836.I5112@fw.wintelcom.net>, Alfred Perlstein writes: >> >> >> 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. >> > >> >Wait a second, didn't you argue against doing this when I proposed it >> >nearly a year ago? >> >> I argued against having only two colors and in favour of three (or >> more) colors. > >I'm sorry, I didn't mean to be short with you, what I remeber is >you being very against callbacks into subsystems to free the RAM, >basically only doing the "free 2, allocate 1" thing when you normally >entered a subsystem, not during a callback which has a lot of lock >ordering problems (your point if I remeber correctly). > >Callbacks can be a bad idea because of lock ordering as well as >possible resource allocation recursion. Well, the callbacks are needed to tell the subsystem that things have changed, but otherwise you're right, the majority of the work should be done "in the normal course of events" with a footnote that going into RED means "anything goes". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?30679.973673716>