H. Peter Anvin wrote:
Followup to: <[email protected]>
By author: Chris Wedgwood <[email protected]>
In newsgroup: linux.dev.kernel
On Thu, Apr 07, 2005 at 09:42:04PM -0700, Linus Torvalds wrote:
Yes. The silly thing is, at least in my local tests it doesn't
actually seem to be _doing_ anything while it's slow (there are no
system calls except for a few memory allocations and
de-allocations). It seems to have some exponential function on the
number of pathnames involved etc.
I see lots of brk calls changing the heap size, up, down, up, down,
over and over.
This smells a bit like c++ new/delete behavior to me.
Hmmm... can glibc be clued in to do some hysteresis on the memory
allocation?
-hpa
Take a look at
http://www.linuxshowcase.org/2001/full_papers/ezolt/ezolt_html/
Abstract
GNU libc's default setting for malloc can cause a significant
performance penalty for applications that use it extensively, such as
Compaq's high performance extended math library, CXML. The default
malloc tuning can cause a significant number of minor page faults, and
result in application performance of only half of the true potential.
This paper describes how to remove the performance penalty using
environmental variables and the method used to discover the cause of the
malloc performance penalty.
Regards,
Rogan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]