Skip site navigation (1)Skip section navigation (2)
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>