performance of 3.14.4 and stack debugging and KSTACKOVERFLOW

[Carlos Carvalho]

It seems that 3.14.4 is slower than 3.13.latest, which is bad here because we run grsec on performance sensitive or critical machines. Could it be because of the mandatory stack debugging?

The latest 3.14.4 introduces KSTACKOVERFLOW. Does it have any implication on performance?

Also, why can't we turn off stack debugging if we choose KSTACKOVERFLOW?

[spender]

Can you provide benchmarks for some reproducible aspect of your workload with KSTACKOVERFLOW enabled and disabled? There will be a hit on process creation/exit and perhaps a small one on context switching as well, but I didn't expect the overall impact to be large. In the patches to be uploaded today I've also removed the DEBUG_STACKOVERFLOW requirement, though the hit from that should have been insignificant.

Thanks,
-Brad

[Carlos Carvalho]

The only clear evidence of worse performance is in the backup machine, which now takes a lot longer to complete the rsyncs. However I jumped from 3.13.10 to 3.14.4, so it may be the kernel and not grsec.

If you say the impact should have been insignificant it's probably something else. I'll test tonight's version without debug and report here in a few days.

[Carlos Carvalho]

In this morning the backup machine had debug stack disabled and the new protection enabled. It's clear that there's no significant performance difference, which means that the stack debugging impact in performance is really negligible.