Re: [PATCH] Stackgap

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 05/30/05

  • Next message: Robert Watson: "Re: [PATCH] randomized mmap" 
    Date: Mon, 30 May 2005 09:38:21 +0100 (BST)
To: Suleiman Souhlal <ssouhlal@FreeBSD.org>

    On Sun, 29 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...
    >
    > I've modified the patch to make sure that the random offset is always
    > correctly aligned.. Do you think it would be safe to commit it (maybe
    > having the stackgap off by default)?

    Have you had a chance to run any micro-benchmarks to confirm all is well?

    Also, I thought Poul-Henning's question about the degree of entropy here
    was interesting -- what's the actual scope of possible values? Are we
    talking about only a small number of offsets (16) or something much
    larger?

    I'm not opposed to it being merged as long as (a) we know it doesn't hurt
    us, and (b) it actually does help us.

    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"

  • Next message: Robert Watson: "Re: [PATCH] randomized mmap"

    Relevant Pages

    • Re: =?ISO-8859-1?Q?int_number_=3D_new_int();?=
      ... I'm still not sure I'd go around assuming that data on the stack is ... from one thread to another is the use of unsafe code. ... "nasty", but I have to admit that not everyone agrees. ... Not necessarily - but anything which is deliberately making stack data ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: linux interrupt handler/bottom half
      ... > grep the sources for that (in a PowerPC distribution) I think you'll find ... have a usable stack. ... There are lot of nasty things user mode code could ... corrupt, which will give you a good chance of a fast ...
      (comp.os.linux.development.system)
    • Re: Global labels in inline assembly.
      ... prepared to deal with all the stack issues and other nasty stuff ... does a lot of bizarre stack manipulations and I'm prepared for all ... and am able to declare public global labels that allow me to do each ...
      (alt.lang.asm)
    • Compress stack unwinder output
      ... The unwinder has some extra newlines, which eat up loads of screen ... for a nasty example). ... if (!stack) { ... unsigned long dummy; ...
      (Linux-Kernel)