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

[Alfred Perlstein]

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

-- 
- Alfred Perlstein