Date: Tue, 4 Nov 2014 15:11:01 +0000 From: Brooks Davis <brooks@freebsd.org> To: Mateusz Guzik <mjguzik@gmail.com> Cc: Hans Petter Selasky <hps@selasky.org>, src-committers@freebsd.org, jmallett@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, Bruce Evans <brde@optusnet.com.au>, Konstantin Belousov <kostikbel@gmail.com>, Julian Elischer <julian@freebsd.org> Subject: Re: svn commit: r274017 - head/sys/kern Message-ID: <20141104151101.GG29192@spindle.one-eyed-alien.net> In-Reply-To: <20141104054144.GB4032@dft-labs.eu> References: <201411030746.sA37kpPu037113@svn.freebsd.org> <54573AEE.9010602@freebsd.org> <54573B87.7000801@freebsd.org> <54573CD2.1000702@selasky.org> <20141103092132.GH29497@dft-labs.eu> <20141103100847.GK53947@kib.kiev.ua> <20141104045159.E1605@besplex.bde.org> <79454.1415043356@critter.freebsd.dk> <20141104054144.GB4032@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
--3O1VwFp74L81IIeR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 04, 2014 at 06:41:44AM +0100, Mateusz Guzik wrote: > re-sent with trimmed cc >=20 > On Mon, Nov 03, 2014 at 07:35:56PM +0000, Poul-Henning Kamp wrote: > > -------- > > In message <20141104045159.E1605@besplex.bde.org>, Bruce Evans writes: > >=20 > > >This optimization is probably minor, but reminds me of other syscalls > > >that would benefit using a single largish allocation up front: > > >- all vfs calls that start with namei(). They allocate PATH_MAX (1K) > > > bytes and more. An 8K stack has plently to spare after allocating > > > 1K. However, if malloc() is used then the PATH_MAX limit shouldn't > > > exist. Only a limit to prevent denial of service is needed. > >=20 > > We should actually roll a new rev of all syscalls which take a path > > and have them pass strlen(path)+1 into the kernel. > >=20 > > That would allow both precise allocation and faster copyin, followed > > by a check that the last byte is (still) a NUL. > >=20 >=20 > I think we can speed up things on amd64 no problem without affecting > userspace. >=20 > amd64's copyinstr (and most likely all others) copy byte by byte. What > we can do is copy word size and fall back to byte by byte on page fault. > Ten on each iteration check if 0 was encountered. As long as you handle unaligned starting addresses, you can safely copy aligned-word by aligned-word without the risk of spurious pagefaults (libc makes this assumption all over the place). You may trip other potential memory protection mechanims which aren't limited to page alignment, but for exisiting hardware you don't need to worry about it. That said, I prefer phk's suggestion in many ways. It places the burden on userspace where it belongs and allows precise allocation in the kernel. -- Brooks --3O1VwFp74L81IIeR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRY7IUACgkQXY6L6fI4GtSzJgCfdjsPH64e93aSXnamG/b/ALnN OcYAn1lwUvhiiCFzmvyuDdVPXZto5DY1 =3q7N -----END PGP SIGNATURE----- --3O1VwFp74L81IIeR--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141104151101.GG29192>