Ali Bahrami wrote:
> Roland Mainz wrote:
> > Why is |resolvepath()| called in the "truss" sample below:
> > -- snip --
> > stat64("/usr/lib/libast.so.1", 0xFFBFEF80)      = 0
> > resolvepath("/usr/lib/libast.so.1", "/usr/lib/libast.so.1", 1023) = 20
> > open("/usr/lib/libast.so.1", O_RDONLY)          = 3
> > mmapobj(3, 0x00020000, 0xFF3F7A48, 0xFFBFF014, 0x00000000) = 0
> > close(3)
> > -- snip --
> >
> > Wouldn't it be easier to just call |open()| directly ?
> >
> > P.S.: Why doesn't the code just do an |open()| for each library
> > _directory_ and then do a |statat()| and |openat()| using the returned
> > file descriptor ? AFAIK this would save some directory lookup time...
> 
> I'm just speculating here --- the deeper answer lies in the source.
> 
> I think that there are there are some assumptions underlying this,
> that the kernel caches recently accessed inodes, that open() is notably
> more expensive than stat and resolvepath, and that ld.so does not end
> up needing to open most of the files it stats.
> 
> ld.so can encounter the same file under more than one name, via symlinks
> in the path or file, and via relative paths vs. fully qualified ones.
> Since it only wants to map each such object once, and because it needs
> to refer to it using a single fully qualified path, resolvepath() is
> used to canonify the path and compare it to what's already loaded before
> opening it.

Ah... Ok... but wouldn't it be simpler to use only the inode information
from the |stat()|-call ?

> I don't know whether openat() would be faster, I suppose it depends on
> level of "recently accessed inode" caching the kernel does. As the ld.so code
> predates openat(), I suspect that this is an experiment that simply hasn't
> been done, probably because this hasn't been seen as a hot spot.

If you are going to measure that please try it with a diskless client or
at least with some libraries coming from NFS (or better: A filesystem
with high latency). My _guess_ is that |openat()| using an existing
directory fd may reduce latency a lot since the NFS client is forced to
keep an active cache entry around.

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Reply via email to