svn commit: r184652 - in head/sys: dev/hwpmc fs/procfs kern

[John Baldwin]

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 
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