| Message ID | 20190123110349.35882-1-keescook@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | gcc-plugins: Introduce stackinit plugin | expand |
On Wed, 23 Jan 2019, Patchwork <patchwork@emeril.freedesktop.org> wrote: > == Series Details == > > Series: gcc-plugins: Introduce stackinit plugin > URL : https://patchwork.freedesktop.org/series/55630/ > State : failure > > == Summary == > > Applying: treewide: Lift switch variables out of switches > Using index info to reconstruct a base tree... > M drivers/gpu/drm/drm_edid.c > M drivers/gpu/drm/i915/intel_display.c > M drivers/gpu/drm/i915/intel_pm.c > Falling back to patching base and 3-way merge... > Auto-merging drivers/gpu/drm/i915/intel_pm.c > CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_pm.c > Auto-merging drivers/gpu/drm/i915/intel_display.c > Auto-merging drivers/gpu/drm/drm_edid.c > error: Failed to merge in the changes. > hint: Use 'git am --show-current-patch' to see the failed patch > Patch failed at 0001 treewide: Lift switch variables out of switches > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". This obviously fails because the patch is against upstream rather than our development tree. No worries. BR, Jani. > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 23.01.2019 14:03, Kees Cook wrote: > This adds a new plugin "stackinit" that attempts to perform unconditional > initialization of all stack variables Hello Kees! Hello everyone! I was curious about the performance impact of the initialization of all stack variables. So I did a very brief test with this plugin on top of 4.20.5. hackbench on Intel Core i7-4770 showed ~0.7% slowdown. hackbench on Kirin 620 (ARM Cortex-A53 Octa-core 1.2GHz) showed ~1.3% slowdown. This test involves the kernel scheduler and allocator. I can't say whether they use stack aggressively. Maybe performance tests of other subsystems (e.g. network subsystem) can show different numbers. Did you try? I've heard a hypothesis that the initialization of all stack variables would pollute CPU caches, which is critical for some types of computations. Maybe some micro-benchmarks can disprove/confirm that? Thanks! Best regards, Alexander
On Mon, Jan 28, 2019 at 4:12 PM Alexander Popov <alex.popov@linux.com> wrote: > > On 23.01.2019 14:03, Kees Cook wrote: > > This adds a new plugin "stackinit" that attempts to perform unconditional > > initialization of all stack variables > > Hello Kees! Hello everyone! > > I was curious about the performance impact of the initialization of all stack > variables. So I did a very brief test with this plugin on top of 4.20.5. > > hackbench on Intel Core i7-4770 showed ~0.7% slowdown. > hackbench on Kirin 620 (ARM Cortex-A53 Octa-core 1.2GHz) showed ~1.3% slowdown. Thanks for looking at this! I'll be including my hackbench measurements for the v2 here in a moment. > This test involves the kernel scheduler and allocator. I can't say whether they > use stack aggressively. Maybe performance tests of other subsystems (e.g. > network subsystem) can show different numbers. Did you try? I haven't found a stable network test yet. If someone can find a reasonable workload, I'd love to hear about it. > I've heard a hypothesis that the initialization of all stack variables would > pollute CPU caches, which is critical for some types of computations. Maybe some > micro-benchmarks can disprove/confirm that? I kind of think micro-benchmarks aren't so useful because they don't represent a real-world workload. I've heard people talk about SAP-HANA as a good test, but I can't get my hands on it. I wonder if anyone has tried "mysqlslap"?