From owner-freebsd-arch@FreeBSD.ORG Mon Oct 6 17:31:21 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB53716A4B3 for ; Mon, 6 Oct 2003 17:31:21 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C92C43FF5 for ; Mon, 6 Oct 2003 17:31:20 -0700 (PDT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id BC6412BC0D for ; Tue, 7 Oct 2003 10:31:17 +1000 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id D057451836; Tue, 7 Oct 2003 10:01:14 +0930 (CST) Date: Tue, 7 Oct 2003 10:01:14 +0930 From: Greg 'groggy' Lehey To: Poul-Henning Kamp Message-ID: <20031007003114.GF47054@wantadilla.lemis.com> References: <200310062220.h96MK7PI061345@dotar.thuvia.org> <26939.1065479790@critter.freebsd.dk> <21229.1065441969@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rWhLK7VZz0iBluhq" Content-Disposition: inline In-Reply-To: <26939.1065479790@critter.freebsd.dk> <21229.1065441969@critter.freebsd.dk> User-Agent: Mutt/1.4i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: arch@freebsd.org cc: Garrett Wollman cc: Mark Valentine Subject: Re: Alignment of disk-I/O from userland. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 00:31:22 -0000 --rWhLK7VZz0iBluhq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Monday, 6 October 2003 at 14:06:09 +0200, Poul-Henning Kamp wrote: > > Some disk controllers require that the memory buffer for a DMA > transfer be aligned on a particular bounday, typically four bytes, > but in some cases larger than that. > > This program, in other words, would be a problem for some of our > disk controllers: > > #include > > int > main(int argc, char **argv) > { > char *p; > > p = malloc(8192); /* page aligned */ > read (0, p + 1, 2048); /* not */ > } This kind of code is explicitly allowed in K&R 2 (page 170 et seq). > Most code which does disk I/O from userland uses malloc'ed buffers for > the sectors and the alignment comes for free, but we currently have > no requirement that it be so. > > How much code (apart from newfs(8)!) would we break by enforcing a > minimum alignment of for instance 16 bytes on disk-I/O requests > from userland ? Quite possibly a lot of third party code over which we have no control. I'm thinking of ibcs2 and Linux stuff, for example. > It would be a trivial matter to do the "bounce-buffering" somewhere > along the road, but I am not convinced it is the right thing to do > because all of sudden some requests would take a performance hit to > do a copy and some would not... I think the bounce buffering is necessary, but should be an emergency measure. It could generate a console message, for example. On Tuesday, 7 October 2003 at 0:36:30 +0200, Poul-Henning Kamp wrote: > > If shitty code breaks, I don't care. We're trying to raise the > standard in and with FreeBSD, we're not trying to lower the bar > to make any visual basic programmer pass. That depends on whether the programmer is a FreeBSD developer or a user. I agree that our own code should be aligned correctly. I don't think it's reasonable to expect all users to adhere to a higher coding standard than they would for, say, Linux. It's not difficult to cater for them, and if you like we can still tell them off when they do it, but I think the code should work nevertheless. People who get bitten by this "bug" won't see the clean design intentions behind it. They'll just know that FreeBSD is broken. Greg -- See complete headers for address and phone numbers. --rWhLK7VZz0iBluhq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE/gglSIubykFB6QiMRAjl+AJ9oYwEvWYvXVyR/TbjWZFe28bLilwCfeLBH KYVKdvQvOLv0gVX1O/D1p4s= =T/Eq -----END PGP SIGNATURE----- --rWhLK7VZz0iBluhq--