svn commit: r184652 - in head/sys: dev/hwpmc fs/procfs kern
jhb at freebsd.org
Mon Nov 10 12:14:17 PST 2008
On Thursday 06 November 2008 10:21:37 am Peter Wemm wrote:
> On Tue, Nov 4, 2008 at 2:50 PM, John Baldwin <jhb at freebsd.org> wrote:
> > On Tuesday 04 November 2008 05:22:47 pm Ivan Voras wrote:
> >> 2008/11/4 John Baldwin <jhb at 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
> >> 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
> > invocation (and that already did not lock the vnode). It then calls
> > 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.
More information about the svn-src-all