Date: Mon, 10 Nov 2008 11:33:51 -0500 From: John Baldwin <jhb@freebsd.org> To: "Peter Wemm" <peter@wemm.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Ivan Voras <ivoras@gmail.com> Subject: Re: svn commit: r184652 - in head/sys: dev/hwpmc fs/procfs kern Message-ID: <200811101133.51947.jhb@freebsd.org> In-Reply-To: <e7db6d980811060721j41e8ab36s6c67251043dbba2b@mail.gmail.com> References: <200811041904.mA4J41dL005103@svn.freebsd.org> <200811041750.08355.jhb@freebsd.org> <e7db6d980811060721j41e8ab36s6c67251043dbba2b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 06 November 2008 10:21:37 am Peter Wemm wrote: > On Tue, Nov 4, 2008 at 2:50 PM, John Baldwin <jhb@freebsd.org> wrote: > > On Tuesday 04 November 2008 05:22:47 pm Ivan Voras wrote: > >> 2008/11/4 John Baldwin <jhb@freebsd.org>: > >> > Author: jhb > >> > Date: Tue Nov 4 19:04:01 2008 > >> > New Revision: 184652 > >> > URL: http://svn.freebsd.org/changeset/base/184652 > >> > > >> > Log: > >> > Remove unnecessary locking around vn_fullpath(). The vnode lock for the > >> > >> Does this affect realpath(3)? (whose non-scalability is often reported > >> for PHP web servers). > > > > realpath(3) calls getcwd(3) (which devolves to __getcwd(2) I think) once per > > invocation (and that already did not lock the vnode). It then calls lstat() > > for each component in the path. The lstat() calls should be using shared > > locks (at least with the recent changes to use shared lookups for UFS in > > HEAD). I imagine the bottleneck is more with lstat() than getcwd(3). > > Neither is helped by the specific changes above. > > Hmm. Would it make sense to provide a helper syscall specifically for > php to use for this? Without having looked at the php code, it sounds > like it might be helpful to have a syscall that returns the path and > an array of stat structs for each path component. Or is php only > doing this because of compatability with non-atomic getcwd() > implementations? Does php even need to do it? We could possibly move realpath(3) into the kernel. svr4 compat has svr4_resolvepath() which I think is basically a realpath(3) in the kernel that only does one pathname lookup rather than N. If that really works then it would probably be a boon. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200811101133.51947.jhb>