Subject: Re: RFC: addition of B_MANAGED and B_NESTED to buf.h and vfs_bio.c
To: Reinoud Zandijk <reinoud@netbsd.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 01/04/2006 16:41:50
--XOIedfhf+7KOe/yw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 05, 2006 at 12:45:06AM +0100, Reinoud Zandijk wrote:
> On Wed, Jan 04, 2006 at 02:16:19PM -0800, Jason Thorpe wrote:
> >=20
> > Except that getbuf() / brelse() imply the use of the caching =20
> > mechanism.  You then set a flag that says "oh, I'm just using this as =
=20
> > an I/O descriptor", which basically makes brelse() mean nothing other =
=20
> > than "pool_put()".
> >=20
> > So, why not just remain consistent with the other parts of the kernel =
=20
> > that already use a buf as an I/O descriptor rather than adding =20
> > something that isn't actually needed just so it can be ripped out =20
> > later anyway?
>=20
> maybe i'm too focused on performace or rather see stuff changed the soone=
r=20
> the better.

Are you sure that these steps are a performance bottleneck?

Yes, if we can not copy, we can have some performance gains. However we=20
need to look at the whole picture. First off, the read-a-buffer-and-copy=20
technique lends itself easily to cross-endian operation. Also, for ffs we=
=20
have the advantage that we read a bunch of inode structures into memory in=
=20
one buffer. So yes, we copy, but one i/o reads multiple inodes in one=20
step. Saving the i/o MORE than outweighs the copies.

> What do you think about the B_NESTED? This would eventually go into the=
=20
> iobuf part and is significant addition in functionality at practically no=
=20
> cost.

I can't tell you what Jason thinks, just what I think. I think that you=20
have a view of how the buffer system works which is different from the=20
majority of the developers. I think you really need to understand how it=20
works now before suggesting changes. Otherwise we can end up in a real=20
mess of conflicting expectations and behaviors.

My understanding of your B_NESTED proposal is that you want to take=20
functionality in genfs and lfs and soon to be in udf and consolidate it.=20
Ok. So show us a diff that does that. Demonstrate that the functionality=20
can be shared by making lfs and genfs use it. A diff doing that will be a=
=20
MUCH stronger arguement that you have factored things correctly and that=20
we end up reducing code duplication.

Take care,

Bill

--XOIedfhf+7KOe/yw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDvGtOWz+3JHUci9cRAlkYAJ4rbJ6bGfXXYICs23UAe0tXe5oRQQCdEbnH
ty7zHK3HPLP6q4CN2blFb2A=
=a78O
-----END PGP SIGNATURE-----

--XOIedfhf+7KOe/yw--