Re: [PATCH] Stackgap

From: Julian Elischer (julian_at_elischer.org)
Date: 05/31/05

  • Next message: Hajimu UMEMOTO: "Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net" 
    Date: Tue, 31 May 2005 10:15:40 -0700
To: Robert Watson <ratson@freebsd.org>

    Stack gap can actually improve performance in some cases..
    the cache for the base of teh stack can become overly flushed by the
    fact that all stacks start with the same offset
    from the page. making this random can actually help this.

    Robert Watson wrote:

    >
    > On Fri, 27 May 2005, Suleiman Souhlal wrote:
    >
    > In the past, substantial performance hits have been measured due to
    > poor stack alignment. Specifically, in combination with less optimal
    > compiler behavior, the results have been pretty nasty. Have you tried
    > micro-benchmarking a series of runs with this stack offset randomness
    > using floating point on stack arguments to see if there's a measurable
    > cost to moving the stack around? Hopefull if all is well, there will
    > be little or no difference, but a small error here could result in a
    > substantial performance hit...

    Stack gap can actually improve performance in some cases..

    the cache for the base of teh stack can become overly flushed by the
    fact that all stacks
    start with the same offset from the page. making this random can
    actually help this.

    >
    >
    > Robert N M Watson
    > _______________________________________________
    > freebsd-arch@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Hajimu UMEMOTO: "Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net"

    Relevant Pages

    • Re: Macros
      ... >> stack?) ... > they do not depend on the sizes or number of local variables (just their ... The CPU is more efficient when it uses the closest L1 cache ... > You can reproduce this scheme for main memory and pagefile: ...
      (microsoft.public.vc.language)
    • Re: Stack and performance
      ... adding an offset to the stack pointer solves the ... My Pentium M has 64-byte L1 cache lines but it's ... It is almost always used when compiling for debugging, but is sometimes as an extra general purpose register when compiling without debug settings. ... I'm not the most knowledgable on such things, but I didn't think that it was a big issue for x86 to use large offsets from the stack pointer, but on some architectures it is. ...
      (comp.lang.asm.x86)
    • Re: Unions in Assembly Language
      ... > uses normal stack calling convention. ... stack is memory, it can break optimal cache usage, because if some memory ... potential of asm, I am convienced one must use asm daily, for years to see ...
      (alt.lang.asm)
    • Re: instruction stack
      ... one thinks of the return stack as holding "return addresses". ... However, in these days of large instruction caches, in which entire ... cache lines are read from the main memory in one transaction, ... implemented using shift register technology. ...
      (comp.lang.forth)
    • Re: stack hogs in kernel
      ... This one, at least, is due to an issue Roman pointed out on hackers@ in the last 24 hours -- a MAXPATHLEN sized buffer on the stack. ... tens of KBs from the kernel. ... Is the concern about L1 data cache footprint, ... get good performance benefits from the essentially free memory management ...
      (freebsd-current)