From owner-freebsd-arch Fri Dec 1 18:58:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id DEFE837B400 for ; Fri, 1 Dec 2000 18:58:25 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id VAA45432; Fri, 1 Dec 2000 21:58:21 -0500 (EST) (envelope-from wollman) Date: Fri, 1 Dec 2000 21:58:21 -0500 (EST) From: Garrett Wollman Message-Id: <200012020258.VAA45432@khavrinen.lcs.mit.edu> To: dg@root.com Cc: arch@freebsd.org Subject: Re: zero copy code review X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: References: Organization: MIT Laboratory for Computer Science Cc: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article 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 (or at least 4.3+Wisconsin NFS) slept for mbufs but panicked if it couldn't allocate a cluster; 4.4 as we got it would drain protocols once, for mbufs only, and then return nil if there were still no mbufs free -- thus causing a page-not-present fault a few instructions later as code which assumed M_WAIT could never fail dereferenced the null pointer. Deadlocks may have been possible under 4.3+NFS, if the kernel wanted to allocate a page of physical memory for more mbufs, but all potentially-available memory was both dirty and backed by NFS (think diskless workstation). My guess is that this is why 4.4 did not sleep. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message