Stack Smashing Protection >=GCC 4.8.3 на десктопе можно отключить?

В случае gentoo based CFLAGS="-O2 -march=native -fno-stack-protector" в make.conf.

Я не парюсь на эту тему. Мне быстродействия и так достаточно.

еще -U_FORTIFY_SOURCE

нужно забенчить

В плане производительности почти не влияет. Флага nossp нет?

Приеду, посмотрю как включал.

В плане производительности почти

в плане производительности, как говорят разработчики, нужно будет немножко пожертвовать в плане производительности, но нужно ли мне эта опция, если у меня не безоспасный сервер, где это может проявится, а обычная рабочая станция.

Флага nossp нет?

где нет? у меня сейчас:

CFLAGS="-march=bdver2 -O2 -pipe"

CFLAGS="-march=bdver2 -O2 -pipe -fno-stack-protector"

CFLAGS="-march=bdver2 -O2 -pipe -U_FORTIFY_SOURCE -fno-stack-protector
собирай так, чтобы наверняка. По дефолту там вроде бы двойка тоже.

На десктопе это не так важно в плане безопасности

Э... ты уверен? На десктопе, где ты пользуешься не стабильными и хорошо протестированными версиями программ, а фиг знает чем, SSP и прочие меры безопасности со стороны компилятора даже важнее, чем на сервере.

Кроме того, снижение производительности должно быть мизерное. Защита стека активируется только для некоторых функций и состоит в помещении одного дополнительного значения в стек и его проверке перед возвратом из функции.

Разумно.

Можешь отключить в gcc-config

Что говорит gcc-config -l ?

А вообще вот: http://wiki.gentoo.org/wiki/Hardened_Gentoo/ru

[1] x86_64-pc-linux-gnu-4.8.3 *

да вот тут выше посоветовали всё-таки не выключать, но я попробую как-нибудь сравнить, если время будет.

Включаю/выключаю через CFLAGS.

на критичных к производительности отключи, для всей системы оставь, как пацаны делают

что за глупости ты постишь? где там в gcc-config что отключать? зачем собирать с nossp? чтобы сборка отвалилась с ошибкой о неизвестных опциях, если где-то таки заданы опции -fstack-protector?

кстати забенчил опции preempt и hz в ядре на его же компиляции в 4ht потока:

preempt 1000hz
real  2m17.590s
real  2m17.759s
real  2m19.693s

server 1000hz
real  2m17.381s
real  2m17.543s
real  2m18.693s

server 100hz
real  2m14.696s
real  2m14.971s
real  2m16.905s

4ht -> 4ре, никаких hyperthreading не имелось в виду

Это настолько очевидный и ожидаемый результат… Ты зря потратил своё время. Кстати попробуй теперь посмотреть динамичное fullhd видео (h264) с server 100hz ядром, мне интересно, что получится. Не забудь CONFIG_NO_HZ отключить.

Эм, разве gcc-config не содержит этих настоек как раз?

Ок, я в принципе сам за ssp и pie

Содержит только когда собран hardened-toolchain (и то это по идее относится только к самому тулчейну и возможно дефолтам, а не к пользовательским флагам), но не в нормальной ситуации, когда используется 1 компилятор для всего.

очевидный и ожидаемый результат

иисус кому-то тоже очевиден. а кодер x264 работает быстрее с 1000hz ядром, например

попробуй теперь посмотреть динамичное fullhd видео (h264

смотрю, всё как обычно

Не забудь CONFIG_NO_HZ отключить.

а от этого падает производительность, правда бенчил раньше

а кодер x264 работает быстрее с 1000hz ядром

это тоже ожидаемо, например

падает производительность

без NO_HZ не интересно, ты вероятно сможешь смотреть видео с NO_HZ, да.

тоже ожидаемо

и почему же

без NO_HZ не интересно

загрузился с nohz=off, в perf top в первой строчке apic_timer_interrupt

видео как игралось, так и играется. ась?

Это как-то связано с таймером прерываний в ядре (и различной степенью утилизации ресурсов), увы я не разбираюсь в подсистемах ядра в достаточной мере, чтобы сказать конкретней. Кстати ещё можно поэкспериментировать с clocksource (tsc hpet acpi_pm и тд), это более интересно. Например jiffies давал лучший результат, чем pit и оба были лучше tsc.

У меня просмотр фуллхд видео утилизирует 1 ядро процессора почти полностью, ты что-то делаешь не так. Может быть плохо сжато, или смотришь через vdpau etc.

неа, не vdpau. скачал 40Mbps h264, грузит одно ядро на 100%, с nohz=off на 150%, да. но не тормозит

кстати на компиляции ядра c nohz=off таки не медленнее

real  2m14.510s
real  2m14.937s
real  2m16.849s