Re: [PATCH] Stackgap
From: Julian Elischer (julian_at_elischer.org)
Date: 05/31/05
- Previous message: Dag-Erling Smørgrav: "Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net"
- In reply to: Robert Watson: "Re: [PATCH] Stackgap"
- Next in thread: Robert Watson: "Re: [PATCH] Stackgap"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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"
- Previous message: Dag-Erling Smørgrav: "Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net"
- In reply to: Robert Watson: "Re: [PATCH] Stackgap"
- Next in thread: Robert Watson: "Re: [PATCH] Stackgap"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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: 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) - Re: Macros
... > of local variables and stack usage. ... > (even though I can't begin
to understand machine code). ... code size and thus increases the risk of cache
misses and the like. ... you can use the inline keyword as a alternative to macros. ...
(microsoft.public.vc.language)