Date: Tue, 04 Nov 2014 07:24:59 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Mateusz Guzik <mjguzik@gmail.com> Cc: Hans Petter Selasky <hps@selasky.org>, src-committers@freebsd.org, Mateusz Guzik <mjg@freebsd.org>, jmallett@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, 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: <82148.1415085899@critter.freebsd.dk> In-Reply-To: <20141104053520.GA4032@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> <20141104053520.GA4032@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- In message <20141104053520.GA4032@dft-labs.eu>, Mateusz Guzik writes: >On Mon, Nov 03, 2014 at 07:35:56PM +0000, Poul-Henning Kamp wrote: >> -------- >> In message <20141104045159.E1605@besplex.bde.org>, Bruce Evans writes: >> >> >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. >> >> We should actually roll a new rev of all syscalls which take a path >> and have them pass strlen(path)+1 into the kernel. >> >> That would allow both precise allocation and faster copyin, followed >> by a check that the last byte is (still) a NUL. >> > >I think we can speed up things on amd64 no problem without affecting >userspace. I think from a design point of view it makes much more sense to let userland do as much work as possible before we enter the kernel, rather than complicate the kernel with "oops we got a page fault" handling. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?82148.1415085899>