From owner-freebsd-hackers Mon Feb 23 16:50:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01125 for freebsd-hackers-outgoing; Mon, 23 Feb 1998 16:50:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA00823; Mon, 23 Feb 1998 16:49:47 -0800 (PST) (envelope-from grog@lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.8.7/8.8.5) with ESMTP id LAA08872; Tue, 24 Feb 1998 11:19:44 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id LAA13500; Tue, 24 Feb 1998 11:19:43 +1030 (CST) (envelope-from grog) Message-ID: <19980224111942.18559@freebie.lemis.com> Date: Tue, 24 Feb 1998 11:19:42 +1030 From: Greg Lehey To: dyson@FreeBSD.ORG, "Justin T. Gibbs" Cc: hackers@FreeBSD.ORG Subject: Re: New SoftUpdates test kit References: <199802221804.LAA06017@narnia.plutotech.com> <199802221913.OAA00737@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199802221913.OAA00737@dyson.iquest.net>; from John S. Dyson on Sun, Feb 22, 1998 at 02:13:16PM -0500 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 22 February 1998 at 14:13:16 -0500, John S. Dyson wrote: > Justin T. Gibbs said: >> >> It has been discussed before that b_driver* should go away. The >> CAM SCSI layer does not use these fields which means that the last >> reference in our code is going away. Please don't add another >> instance. Struct bufs are pervasive and keeping their size small >> enough to be efficiently allocated is important. I'd have to go >> look to see how close we are to a power of two in size right now, >> but even if removing these fields doesn't shrink us down a malloc >> bucket size, it will give us room to add things like pointers for >> buffer chaining for larger than 64k I/O requests. >> > Normally, we use statically allocated buffers (out of the p(hysical)buf > queue or the normal vfs_bio queue.) Except in the case of getccdbuf > and other schemes that can be deadlock prone, we generally don't allocate > buffers in a dynamic (and slightly more dangerous fashion.) The restriction > of power-of-two should probably go away with our allocator(s) anyway. It is > probably a good idea to use getpbuf rather than getccdbuf or whatever so that > whatever evil that might exist in our buffer implementation can be hidden. > Our allocators need to be cache-line-savvy, not pow-2-alignment-savvy, if we > need to optimize performance. How much difference does this make with a structure which is 292 bytes long? > The problems with getccdbuf aren't about alignment, but resource deadlock > issues, and also data transparency issues. Eventually, we need to more > coherently address the issues of resource deadlocks, but right now, the > best thing to do is to avoid dynamic allocations for things like buffer > headers, and make sure that there is enough of them, or be *extremely* > careful about their usage (using reservation or other primitive scheme > until we can adopt a better system-wide mechanism.) (That is one reason > why swap-paging with CCD or a UFS file is not a good idea, as of now. > Depending on vnode-paging is also problematical, but in practice much > less of a problem.) Wouldn't it make sense to issue a warning message when the free buffers go below a certain threshhold? Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message