Date: Wed, 22 Jan 2003 21:22:31 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@mu.org> Cc: "M. Warner Losh" <imp@bsdimp.com>, bmilekic@unixdaemons.com, hsu@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <200301230522.h0N5MVwQ018334@apollo.backplane.com> References: <dillon@apollo.backplane.com> <0H94005IYWJT1Z@mta5.snfc21.pbi.net> <20030122162531.B77209@unixdaemons.com> <20030122.215336.55300145.imp@bsdimp.com> <20030123050542.GX42333@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:Encouraging the user to use M_NOWAIT to get around all these problems
:is not a solution.
:
:Either locks are being held too long, or allocations are being done
:in the wrong places.
:
:When we have proper priority inheritance and low memory callbacks
:then we will not have to worry about latency.
:
:M_NOWAIT should be the exception if even allowed at all.
:
:--
:-Alfred Perlstein [alfred@freebsd.org]
Well, we are going to have issues with memory allocated by an interrupt
even after interrupts are totally unwound from Giant. Even using interrupt
threads we cannot afford to block in an allocation because that would
introduce unexpected and unbounded latencies. That's a pretty big
reason for M_NOWAIT to stick around, especially considering the work
being done to consolidate all the memory allocation code. Before we
had zalloc(), zalloci(), and malloc() with or without M_NOWAIT. Now
it is all being consolidated.
I would argue that we will need M_NOWAIT for a long time to come.
Thread or not, interrupts are still special.
The M_WAIT issue is not one of interface correctness or historical
compatibility. It has been amply shown that the malloc interface has
been misused by kernel programmers over the years. What Warner is
asking (and I think this is a good idea too), is to try to reduce
such incidences by making developers more aware of the blocking nature
of the interface. Making M_WAITOK and M_NOWAIT both explicit bits
accomplishes this. We then clean up all the current code and add a
warning printf() to catch any remaining cases where neither bit is
set (we default to M_WAITOK for those cases after printing the warning).
This would help solve one of the two most serious issues we have in
the memory subsystem. The second issue is what to do when we run out of
KVM. Right now even a normal allocation will return NULL and most of
the kernel just assumes that *malloc() never returns NULL. The result
is a random crash with an obscure panic (usually a trap on a low memory
address). That has caused us no end of diagnostic trouble in -stable.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200301230522.h0N5MVwQ018334>