From owner-freebsd-hackers Sun Feb 22 11:13:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA26292 for freebsd-hackers-outgoing; Sun, 22 Feb 1998 11:13:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA26279 for ; Sun, 22 Feb 1998 11:13:41 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id OAA00737; Sun, 22 Feb 1998 14:13:16 -0500 (EST) (envelope-from toor) Message-Id: <199802221913.OAA00737@dyson.iquest.net> Subject: Re: New SoftUpdates test kit In-Reply-To: <199802221804.LAA06017@narnia.plutotech.com> from "Justin T. Gibbs" at "Feb 22, 98 11:04:14 am" To: gibbs@narnia.plutotech.com (Justin T. Gibbs) Date: Sun, 22 Feb 1998 14:13:16 -0500 (EST) Cc: grog@lemis.com, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. 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.) -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message