From owner-freebsd-arch@FreeBSD.ORG Thu Dec 20 20:15:28 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8DB1B52; Thu, 20 Dec 2012 20:15:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4FAE88FC0A; Thu, 20 Dec 2012 20:15:28 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBKKFNDh009632; Thu, 20 Dec 2012 22:15:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBKKFNDh009632 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBKKFN9k009631; Thu, 20 Dec 2012 22:15:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 20 Dec 2012 22:15:23 +0200 From: Konstantin Belousov To: Ivan Voras Subject: Re: Unmapped I/O Message-ID: <20121220201523.GD53644@kib.kiev.ua> References: <20121219135451.GU71906@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9dgjiU4MmWPVapMU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 20:15:29 -0000 --9dgjiU4MmWPVapMU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 20, 2012 at 11:49:18AM +0100, Ivan Voras wrote: > On 19/12/2012 14:54, Konstantin Belousov wrote: >=20 > > Besides not mapped buffers, not mapped BIOs are introduced, marked > > with the flag BIO_NOTMAPPED. Unmapped buffers are directly translated > > to unmapped BIOs. Geom providers may indicate an acceptance of the > > unmapped BIOs. If provider does not handle unmapped i/o requests, > > geom now automatically establishes transient mapping for the i/o > > pages. >=20 > Hi, >=20 > Can you write up more details on what this means for GEOM developers: > what is to be gained / lost (on GEOM level) for existing GEOM classes, > and how to "indicate acceptance" for umapped BIOs? Nothing is changed for existing GEOM classes, and it does not mean anything for GEOM developers, unless she wants to change the GEOM class to handle unmapped BIOs. Did you looked at the patch ? Look at the changes for struct bio and geom_vfs.c. Geoms which accept unmapped BIOs now could get either mapped bio, not different from the current one, or unmapped bio, where the bio_data is invalid, and array of the vm_pages bio_ma is passed with bio_ma_offset offset specifying the start position of the data in the first page of the array. Unless provider explicitely agreed to accept unmapped BIOs, it would never get them. --9dgjiU4MmWPVapMU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDTcdsACgkQC3+MBN1Mb4jY4gCfV3TsBdk5E9TfHqmrkwoLsKUJ 41MAoN+36nNeofx0UyKaKO2YPOgtMQW6 =nKCt -----END PGP SIGNATURE----- --9dgjiU4MmWPVapMU--