From owner-svn-src-all@FreeBSD.ORG Sat Jan 28 13:56:25 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3699106564A; Sat, 28 Jan 2012 13:56:25 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 7702F8FC0C; Sat, 28 Jan 2012 13:56:25 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 64B437B2; Sat, 28 Jan 2012 14:56:23 +0100 (CET) Date: Sat, 28 Jan 2012 14:55:10 +0100 From: Pawel Jakub Dawidek To: K Macy Message-ID: <20120128135509.GE2135@garage.freebsd.pl> References: <201201272018.q0RKIWUD055070@svn.freebsd.org> <20120128083954.GD2135@garage.freebsd.pl> <6A52DB46-4897-4D35-B727-2C3D3D01CE9C@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HeFlAV5LIbMFYYuh" Content-Disposition: inline In-Reply-To: <6A52DB46-4897-4D35-B727-2C3D3D01CE9C@gmail.com> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , Kip Macy Subject: Re: svn commit: r230623 - in head/sys: amd64/amd64 cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs sys vm X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 13:56:25 -0000 --HeFlAV5LIbMFYYuh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 28, 2012 at 01:36:05PM +0100, K Macy wrote: > Il giorno 28/gen/2012, alle ore 09:39, Pawel Jakub Dawidek ha scritto: > > How do you handle the case when there are two small allocations within > > one page, where one has the NODUMP flag and one doesn't have the flag? >=20 > Kmem_alloc and zone creation both work at granularities greater than or e= qual to a page. The per-page management of dump is why this flag is not ava= ilable to generic malloc. Hmm, kmem_alloc() in ZFS code is just a wrapper around generic malloc(9). You only added NODUMP flag for zio_data_buf_alloc(), but I think you can pass sizes smaller than eg. 4kB to that function (starting =66rom SPA_MINBLOCKSIZE, which is 512 bytes). How can you tell some other ZFS code that uses kmem_alloc() won't share the same page as small ZIO buffer? I'd like to use that flag with GELI with generic malloc(9). How can I do that? Maybe defining this property at MALLOC_DEFINE() time for the entire malloc type would be better? I could then use two separate malloc types in GELI: one for sensitive data and one for other data. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --HeFlAV5LIbMFYYuh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8j/j0ACgkQForvXbEpPzTDcACgrvJVC1UPYmM6u8s2QcdvZYwC WdAAoO1ib2hxKCBP94nWU+8x+TzPYZrt =Aw97 -----END PGP SIGNATURE----- --HeFlAV5LIbMFYYuh--