Re: hwcap supporting architectures?
At Sun, 16 Jan 2005 20:55:28 +0100,
Falk Hueffner wrote:
> Marcelo E. Magallon writes:
>
> > On Sat, Jan 15, 2005 at 10:14:15PM +0900, GOTO Masanori wrote:
> >
> > > > occurs when you have for example an ev56 library in lib/ev56, and a
> > > > ev67 CPU. Then the loader looks in lib/ev67 and then falls back to
> > > > lib. Since glibc is very carefully undocumented in this area [1], I
> > > > didn't want to try to change this, but rather assumed one could add
> > > > a symlink.
> > >
> > > Yes, and if ev67 is instruction upper compatible with ev56 (I guess
> > > so), I think it's acceptable to add a symlink "ln -sf
> > > lib/ev67/libfoo.so lib/ev56/libfoo.so".
> >
> > Ugh... that pushes the burden of maitaining support for new
> > architectures to the package.
Yeah - I think it's trade off - whether we support library
optimization package or we don't get a bit performance improvement.
> > Please bear with me, but I'm trying
> > to understand the issue: is the cost of calling access(2) or stat(2)
> > really so high?
>
> I'd consider it quite acceptable in this case. However, as I tried to
> express, it's not possible with glibc's current "design", and I didn't
> feel like changing that.
Note that we should keep in mind: imagine most binaries on all debian
system over the world start to consume access(2)/stat(2) system call
cost in each binary execution time - "Many a little makes a mickle".
> > I see for example that on start up the file /etc/ld.so.nohwcap is
> > accessed multiple times (and it's not present, isn't that a race?
> > what happens if the file suddenly appears in the middle of program
> > start up? what's that file anyway, I can't find it mentioned in the
> > documentation).
>
> It's supposed to disable the use of hwcaps. Stating it multiple times
> seems like a bug.
Debian glibc has been applied a special patch to check
/etc/ld.so.nohwcap before loading libraries each time. You can see it
in debian-glibc package ldso-disable-hwcap.dpatch written by Ben and
Daniel. It enables us to upgrade smoothly even if we use optimized
libraries - this effort is one of debian's nice features. But the
drawback is it needs to pay access(2) lookup cost as you pointed out.
Checking /etc/ld.so.nohwcap each time (some binaries call multiple
times) is the current patch design - I think this is safer than
checking /etc/ld.so.nohwcap once in program startup time. However,
yes, it affects execution time for short life programs. I think it's
acceptable because it's one of debian's nice feature...
Regards,
-- gotom
Reply to: