Messages in this thread | | | From | Al Boldi <> | Subject | Re: [PATCH] x86: Don't randomize stack unless current->personality permits it | Date | Tue, 18 Jul 2006 08:21:45 +0300 |
| |
Paulo Marques wrote: > Al Boldi wrote: > >[...] > void fn() { > > > > long i = 9999999; > > double x,y; > > > > elapsed(1); > > while (i--) fn2(&x,&y); > > printf("%4lu ",elapsed(0)); > > } > > You are not initializing x and y and with -Os at least my gcc really > uses floating point load/store operations to handle that code.
Thanks for pointing that out.
I was really waiting for someone to critique this, but keep in mind this code tries to surface a performance problem, and any modification changes the semantics of the compiled code, which then may yield different results.
> Maybe the coprocessor has a hard time normalizing certain garbage on the > stack, but without/with randomization the data comes from other > addresses and you're just lucky with the contents.
Good point, but this random garbage makes the test even more realistic, as this code would thus cover more variations without actually coding for it.
> Does this also happens if you add a "x=0, y=0;" line to that function?
with arch_stack_align using 0xf gcc -Os tstExec.c randomization on causes 2x blips/hits randomization off causes no blips/hits mv a.out tstExec causes continuous 2x slowdown sh -c ./tstExec causes slowdown to disappear (can somebody explain this weirdness?)
with arch_stack_align using 0x7f all weirdness is gone gcc -O3 tstExec.c randomization on causes some minor blips/hits randomization off causes even less blips/hits
Going one step further, with #define arch_stack_align(x) (x) all blips/hits/weirdness are gone
Which means that either arch_stack_align isn't necessary at all, or randomization isn't working as intended.
Can somebody prove me wrong here?
Thanks!
-- Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |