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 ...

[Ruslan Ermilov]

On Tue, Mar 25, 2008 at 12:19:30PM -0700, Alfred Perlstein wrote:
> * Ruslan Ermilov <ru at 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 at FreeBSD.org
FreeBSD committer