svn commit: r274017 - head/sys/kern

[Mateusz Guzik]

re-sent with trimmed cc

On Mon, Nov 03, 2014 at 07:35:56PM +0000, Poul-Henning Kamp wrote:
> --------
> In message <20141104045159.E1605 at 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.

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.

Maybe there will be a way of doing it in even in C without much hassle.

-- 
Mateusz Guzik <mjguzik gmail.com>