[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hwcap supporting architectures?

On Wed, Jan 19, 2005 at 09:43:18AM +0100, Bernd Eckenfels wrote:

 > I agree with you, but dont forget that this micro benchmark does not
 > really measure the overall effect on the system (i.e. to other
 > programs, to the number of meta data updates, cach useage) and it
 > does not take into account slow or unreachable path components (nfs).


 The intention of the benchmark is not to claim that the operation that
 ld.so is performing is fast; it's just to provide some quantifiable
 argument for or against the "system calls are way too expensinve" meme.

 *My* position is that whilst they are expensive (certainly much more
 expensive than a function call), they are not _that_ expensive.

 Before asking here I went thru several mailing list archives.  What I
 found was a general argument along the lines of "don't add _that_ hwcap
 because that will increase the size of the list of paths that you have
 to stat(2) in order to find the library and that's slow".  In
 particular upstream doesn't seem to like the idea much.  I just can't
 find the reason why they think the stat(2) call is _so_ expensive that
 it will hurt system performance.  There was some mention of a glib
 issue with plugins.  I couldn't find further data points on that...

 > So it might be actually noticeable on normal systems (I doubt it).
 > Just dont stop anyone volunteering from fixing it. I for one are
 > happy if the strace of a process keeps readable in finite time, so do
 > system administrators with auditing turned on.

 I can understand that.  I'm just not sure what's to fix in the first


Reply to: