From owner-freebsd-arch Wed Jan 22 21:22:36 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACAA237B401; Wed, 22 Jan 2003 21:22:34 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 271B743ED8; Wed, 22 Jan 2003 21:22:34 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0N5MV0i018335; Wed, 22 Jan 2003 21:22:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0N5MVwQ018334; Wed, 22 Jan 2003 21:22:31 -0800 (PST) Date: Wed, 22 Jan 2003 21:22:31 -0800 (PST) From: Matthew Dillon Message-Id: <200301230522.h0N5MVwQ018334@apollo.backplane.com> To: Alfred Perlstein Cc: "M. Warner Losh" , bmilekic@unixdaemons.com, hsu@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step References: <0H94005IYWJT1Z@mta5.snfc21.pbi.net> <20030122162531.B77209@unixdaemons.com> <20030122.215336.55300145.imp@bsdimp.com> <20030123050542.GX42333@elvis.mu.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message