Date: Sun, 18 Jan 2004 14:57:06 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Scott Long <scottl@freebsd.org>, freebsd-hackers@freebsd.org, Paul Twohey <twohey@CS.Stanford.EDU>, scsi@freebsd.org Subject: Re: [CHECKER] bugs in FreeBSD Message-ID: <200401182257.i0IMv63i097663@apollo.backplane.com> References: <Pine.LNX.4.44.0401161607260.26554-100000@Xenon.Stanford.EDU> <20040118160802.GC32115@FreeBSD.org.ua> <200401181844.i0IIivlQ096389@apollo.backplane.com> <400AE3AB.1070102@freebsd.org> <200401181957.i0IJvFTe096883@apollo.backplane.com> <200401182238.i0IMcQYZ097543@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: M_NOWAIT is being used pretty much as if it were M_WAITOK|M_USE_RESERVE
: most of the time, especially considering the side effect situation when
: such allocations fail. I don't think M_WAITOK|M_USE_RESERVE would be
: any less reliable, actually. It looks like the whole paradigm has
: shifted away from the original definition of M_NOWAIT to something that
: is more like a cross between M_NOWAIT, M_WAITOK, and M_USE_RESERVE.
oops, don't take that literally. M_USE_RESERVE means something else.
M_NOWAIT is triggering VM_ALLOC_INTERRUPT which is allowed to dig into
the free (vm) page reserve.
Another interesting thing I've found, and correct me if I'm wrong,
but it looks like when the 5.x slab allocator allocates M_NOWAIT memory
that newly allocated zone becomes available for normal M_WAITOK
allocations as well. This is something DFly's slab allocator does
too (I have a big XXX comment for it), and the 4.x allocator too I think.
That could create an exhaustion issue.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401182257.i0IMv63i097663>