Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 02 Dec 2000 14:07:03 -0800
From:      David Greenman <dg@root.com>
To:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc:        arch@freebsd.org
Subject:   Re: zero copy code review 
Message-ID:  <200012022207.OAA16275@implode.root.com>
In-Reply-To: Your message of "Fri, 01 Dec 2000 21:58:21 EST." <200012020258.VAA45432@khavrinen.lcs.mit.edu> 

next in thread | previous in thread | raw e-mail | index | archive | help
>In article <mit.lcs.mail.freebsd-arch/200012020202.SAA14681@implode.root.com> you write:
>
>>   FreeBSD blocked indefinitly and never returned a NULL pointer.
>
>It has never been like that in the FreeBSD era, to my knowledge.  4.3

   What we're in dispute over is what happens when the kernel runs out
of virtual memory - "mb_map" space. I'm pretty certain that FreeBSD
versions < 2.0 did just sleep when running out of mb_map space, although
I don't have the code around to verify this claim. It's interesting to
note that a process that went to sleep on the map would never wake up
since virtual memory allocated to network buffers was never returned to
the map and thus the kernel would never satisfy the VM shortage. In
FreeBSD 2.0, however, the kernel paniced when running out of mb_map space
with a "mb_map full" panic. It did not return a NULL pointer in the M_WAIT
case. Starting with FreeBSD 2.0.5, FreeBSD printed a console message and
returned a NULL pointer when running out of mb_map. I should have remembered
this better since I was the one who made the change for it to do this in
rev 1.9 of uipc_mbuf.c.
   Going back to 4.3 BSD, I see that the code behaved the same way that
FreeBSD 2.0 did, specifically in m_clalloc:

        mbx = rmalloc(mbmap, (long)npg);
        if (mbx == 0) {
                if (canwait == M_WAIT)
                        panic("out of mbufs: map full");
                return (0);
        }

   My main point was that it used to be a safe assumption that a NULL pointer
wasn't returned in the M_WAIT case. Now that I see that I was the one who
originally broke this assumption, I feel a bit sheepish, so I'll just crawl
away quietly and let this discussion progress. :-)

-DG

David Greenman
Co-founder, The FreeBSD Project - http://www.freebsd.org
President, TeraSolutions, Inc. - http://www.terasolutions.com
Pave the road of life with opportunities.


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?200012022207.OAA16275>