Date: Sun, 22 Feb 1998 14:13:16 -0500 (EST) From: "John S. Dyson" <dyson@FreeBSD.ORG> To: gibbs@narnia.plutotech.com (Justin T. Gibbs) Cc: grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: New SoftUpdates test kit Message-ID: <199802221913.OAA00737@dyson.iquest.net> In-Reply-To: <199802221804.LAA06017@narnia.plutotech.com> from "Justin T. Gibbs" at "Feb 22, 98 11:04:14 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802221913.OAA00737>