Date: Wed, 26 Mar 2008 01:42:28 +0300 From: Ruslan Ermilov <ru@freebsd.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/en midway.c src/sys/dev/fatm if_fatm.c src/sys/dev/firewire if_fwe.c if_fwip.c src/sys/dev/iscsi/initiator isc_soc.c src/sys/kern subr_mchain.c uipc_mbuf.c uipc_socket.c uipc_syscalls.c src/sys/net bpf.c ... Message-ID: <20080325224228.GB93187@team.vega.ru> In-Reply-To: <20080325191930.GD67856@elvis.mu.org> References: <200803250939.m2P9d3RC028128@repoman.freebsd.org> <20080325180152.GB67856@elvis.mu.org> <20080325183750.GA51894@team.vega.ru> <20080325191930.GD67856@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 25, 2008 at 12:19:30PM -0700, Alfred Perlstein wrote: > * Ruslan Ermilov <ru@freebsd.org> [080325 11:37] wrote: > > On Tue, Mar 25, 2008 at 11:01:52AM -0700, Alfred Perlstein wrote: > > > I don't think this was thought out enough, there are times when you > > > would want to limit the total memory allocated to mbufs and avoid > > > deadlocks in low memory situations. > > > > > > Even the old allocator could have been trivially modified to block > > > forever upon exhaustion of the mbuf arena. > > > > > > The reason why the old allocator was not "fixed" to block forever > > > was to allow for recovery from low memory deadlocks. > > > > > > A lot of work went into making the system safe in the face of these > > > deadlocks and removing it "to clean up" due to a deficiency with > > > the current allocator and without understanding why it was there > > > in the first place is a mistake. > > > > > > This whole thing needs to be backed out. > > > > > Are you (or anyone else you know) planning to work on adding real > > support for M_TRYWAIT? > > I would like to eventually, I think because my place of work moved > from 4.x to 6.x recently it will become an issue for us and we will > need to track it down, this will likely fall on my lap. Presently > the uma panics the machine when exhaustion happens, something that > can be averted by capping mbuf space. > > I spoke to John Baldwin about it and he said "it would be nice" and > would fix a number of panics at his place. That said he seems to > think that this change is OK as we'll just re-add the NULL checks > later on. He doesn't seem to support the backout or not support > it, no idea. > > However I'm not OK with it, because we spent many cycles fixing all > of these and new code will likely just assume the old thing which > will cause it to need substantial refactoring (see NFS history) to > be fixed or re-fixed. > > That said I don't have immediate plans for it, but I see it as a > requirement again as the userbase of 6.x and beyond grows. > Yes, it'd be nice to have the semantics M_TRYWAIT originally supposed to provide, but 1) it never worked as planned, and 2) four years have passed since MBUMA, and the code has rotten: some of it treated M_TRYWAIT as M_WAIT, some as "try to wait" (sometimes mixed in the single file), and some newer code now uses UMA flags M_WAITOK/M_NOWAIT directly, as hinted in mbuf.h. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080325224228.GB93187>