Вопрос по установке на HP mini

Первым делом, скажу - устанавливается (с него и пишу).
Тип - вот этот:
http://flashcom.ru/market/noutbuki/46342-HP_Mini_110-3706er_QC074EA_Black_N570

Но вопрос по ключам компилятора для atom N570.

Нашел руководство по asus (в качестве общего)
http://www.calculate-linux.ru/blogs/ru/290/show
(за что большое спасибо автору)
и ответ на вопрос по atom n 270
http://www.calculate-linux.ru/boards/16/topics/10988?r=12223#message-12223

Вопрос собственно в том, что ключи, указанные для atom N270 будут ли способствовать ускорению на atom N570? Архитектура та же (вроде бы), только кэш больший.

Сейчас посмотрим. По идее должны быть минимальные изменения.

Этот процессор должен быть раза в два шустрее. У него честных 2 ядра и каждое может вытягивать 2 потока по гипертрейдингу. Кроме этого кеш L2 действительно в сумме 1024к по 512к на каждое ядро. Размеры кеша L1 на каждое ядро аналогичны n270. Инструкции совпадают с процессором n270.

Основное отличие это два ядра вместо одного.

В make.conf вместо MAKEOPTS="-j3" пишем MAKEOPTS="-j5"

Ежели ядро компилируем ручным способом, то из каталога /usr/src/linux применяем команду

make -j5 && make modules_install install && module-rebuild -X rebuild

Что касательно выставления размера кеша… Тут более сложная головоломка, так как нигде не встречал описание какая стратегия применяется при наличие более одного ядра… То ли нужно выставлять 512к на каждое, то ли 1024к общие на все. Стоит провести эксперимент.

в make.conf сначала устанавливаем, к примеру:

*CFLAGS="-O3 -march=native -mtune=native -fomit-frame-pointer -pipe --param l1-cache-line-size=64 --param l1-cache-size=24 --param l2-cache-size=512 -mmmx -msse -msse2 -msse3 -mssse3 -ffast-math -mfpmath=both -fexcess-precision=fast -fmerge-all-constants -fno-gcse -funroll-all-loops -g0 -Wno-all"
CXXFLAGS="${CFLAGS}"*

и компилируем emerge nbench, затем запускаем nbench и смотрим какие результаты теста он покажет.

После этого в make.conf меняем параметры на:

*CFLAGS="-O3 -march=native -mtune=native -fomit-frame-pointer -pipe --param l1-cache-line-size=64 --param l1-cache-size=24 --param l2-cache-size=1024 -mmmx -msse -msse2 -msse3 -mssse3 -ffast-math -mfpmath=both -fexcess-precision=fast -fmerge-all-constants -fno-gcse -funroll-all-loops -g0 -Wno-all"
CXXFLAGS="${CFLAGS}"*

Повторяем emerge nbench и запускаем на тест.

Соответственно выбираем тот вариант кеша, в котором результаты тестирования выше. По идее должно сработать. Вместо nbench можно использовать другие программы тестирования производительности. Nbench показывает производительность 1 ядра. В Вашем случае одного из 4-х виртуальных.

На текущий момент я использую параметры компиляции для программ:

CFLAGS="-O3 -march=native -mtune=native --param l1-cache-line-size=64 --param l1-cache-size=32 --param l2-cache-size=512 -msahf -mcx16 -mmmx -msse -msse2 -msse3 -mssse3 -mfpmath=both -fmerge-all-constants -fexcess-precision=fast -fomit-frame-pointer -fno-align-functions -fno-align-loops -fno-align-labels -fno-align-jumps --param max-unroll-times=4 --param max-unrolled-insns=72 --param max-average-unrolled-insns=216 -funroll-all-loops -fno-gcse -g0 -Wno-all -pipe"

В случае, если какая-нибудь специфическая программа не захочет компилироваться, то просто выкидываем разворот циклов: –param max-unroll-times=4 --param max-unrolled-insns=72 --param max-average-unrolled-insns=216 -funroll-all-loops и компилируем ее. Пока сталкивался с этим только в отдельных версиях libreoffice. Причин не знаю. Однако в некоторых программах даже небольшой разворот циклов очень прилично ускоряет программы на атоме и полностью отказываться от него не желательно.

Для ядра аналогично в /usr/src/linux/Makefile комментируем строки

*#HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer
#HOSTCXXFLAGS = -O2*

и устанавливаем (только подставьте нужный размер кеша L2)

HOSTCFLAGS = -O3 -march=native -mtune=native --param l1-cache-line-size=64 --param l1-cache-size=32 --param l2-cache-size=512 -msahf -mcx16 -mfpmath=387 -fmerge-all-constants -fexcess-precision=fast -fomit-frame-pointer -fno-align-functions -fno-align-loops -fno-align-labels -fno-align-jumps --param max-unroll-times=4 --param max-unrolled-insns=72 --param max-average-unrolled-insns=216 -funroll-all-loops -fno-gcse -g0 -Wno-all -pipe

HOSTCXXFLAGS = $(HOSTCFLAGS)

ищем параметры

CFLAGS_MODULE и CFLAGS_KERNEL и также выставляем
*
CFLAGS_MODULE = $(HOSTCFLAGS)
CFLAGS_KERNEL = $(HOSTCFLAGS)*

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

Пока проверил два варианта.

Результат:

TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
-------------------:-----------------:------------:-----------
NUMERIC SORT : 583.2 : 14.96 : 4.91
STRING SORT : 132.56 : 59.23 : 9.17
BITFIELD : 3.0359e+08 : 52.08 : 10.88
FP EMULATION : 117.64 : 56.45 : 13.03
FOURIER : 8397.8 : 9.55 : 5.36
ASSIGNMENT : 18.924 : 72.01 : 18.68
IDEA : 2181.5 : 33.37 : 9.91
HUFFMAN : 1065.9 : 29.56 : 9.44
NEURAL NET : 10.987 : 17.65 : 7.42
LU DECOMPOSITION : 565.16 : 29.28 : 21.14
ORIGINAL BYTEMARK RESULTS
INTEGER INDEX : 40.698
FLOATING-POINT INDEX: 17.025
Baseline (MSDOS**) : Pentium** 90, 256 KB L2-cache, Watcom* compiler 10.0
LINUX DATA BELOW=
CPU : 4 CPU GenuineIntel Intel® Atom™ CPU N570 @ 1.66GHz 1000MHz
L2 Cache : 512 KB
OS : Linux 3.1.6-calculate
C compiler : i686-pc-linux-gnu-gcc
libc :
MEMORY INDEX : 12.304
INTEGER INDEX : 8.795
FLOATING-POINT INDEX: 9.443
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
Trademarks are property of their respective holder.

TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
-------------------:-----------------:------------:-----------
NUMERIC SORT : 583.68 : 14.97 : 4.92
STRING SORT : 135.36 : 60.48 : 9.36
BITFIELD : 3.035e+08 : 52.06 : 10.87
FP EMULATION : 115.07 : 55.22 : 12.74
FOURIER : 8375.2 : 9.53 : 5.35
ASSIGNMENT : 18.115 : 68.93 : 17.88
IDEA : 2180.2 : 33.34 : 9.90
HUFFMAN : 1066.8 : 29.58 : 9.45
NEURAL NET : 10.879 : 17.48 : 7.35
LU DECOMPOSITION : 565.2 : 29.28 : 21.14
ORIGINAL BYTEMARK RESULTS
INTEGER INDEX : 40.442
FLOATING-POINT INDEX: 16.954
Baseline (MSDOS**) : Pentium** 90, 256 KB L2-cache, Watcom* compiler 10.0
LINUX DATA BELOW=
CPU : 4 CPU GenuineIntel Intel® Atom™ CPU N570 @ 1.66GHz 1000MHz
L2 Cache : 512 KB
OS : Linux 3.1.6-calculate
C compiler : i686-pc-linux-gnu-gcc
libc :
MEMORY INDEX : 12.209
INTEGER INDEX : 8.749
FLOATING-POINT INDEX: 9.403
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

  • Trademarks are property of their respective holder.

В принципе одно и то же. Поставлю вариант к кэшем - 512 и не буду заморачиваться.

Пока начну с ядра, только разворачивание циклов отключу :slight_smile: По результатам отпишусь (попробую по крайней мере)

Судя по результат полный разворот циклов в nbench вмещается в 512к… Сейчас попробую подобрать команду, которой можно проверить эффективность кеша L2. Разворот циклов отключай - на общую производительность системы сильно влиять не будет.

Что у тебя показывает у тебя # cat /sys/devices/system/cpu/cpu0/cache/index2/size?

Есть еще хороший вариант пробить какой кеш L2 оптимален на 1 ядро экспериментально:

$ sysbench --test=memory --memory-block-size=128K --max-time=30 run

78609.50 MB transferred (2620.29 MB/sec)

$ sysbench --test=memory --memory-block-size=256K --max-time=30 run

86315.50 MB transferred (2877.15 MB/sec)

$ sysbench --test=memory --memory-block-size=512K --max-time=30 run

62998.50 MB transferred (2099.92 MB/sec)

$ sysbench --test=memory --memory-block-size=1024K --max-time=30 run

40379.00 MB transferred (1345.92 MB/sec)

Отсюда видно, что наилучший результат для atom n270 - 86315.50 MB transferred (2877.15 MB/sec), а значит кеш L2=256К будет оптимальным - мне самому надо перебирать систему (у меня установлено 512К сейчас)… У Вас скорее всего тоже установка значения 256К покажет лучший результат на atom N570, так как кеш всего 1024К, а виртуальных ядер будет уже 4.

P.S.

Если sysbench не установлен, то вначале устанавливаем emerge sysbench.

#cat /sys/devices/system/cpu/cpu0/cache/index2/size
512 K

sysbench --test=memory --memory-block-size=128K --max-time=30 run
80859.12 MB transferred (2695.28 MB/sec)

sysbench --test=memory --memory-block-size=256K --max-time=30 run
90526.25 MB transferred (3017.51 MB/sec)

sysbench --test=memory --memory-block-size=512K --max-time=30 run
81594.00 MB transferred (2719.76 MB/sec)

sysbench --test=memory --memory-block-size=1024K --max-time=30 run
46810.00 MB transferred (1560.29 MB/sec)

Полез править конфиги под 256К кэша Зря ядро пересобирал…

Не зря - оно уже шустрее;) Я, как видишь, сам ошибался. Но это должно еще добавить резвости. Тоже ядро поставил перебирать)

Облом. Ядро собралось, но грузиться отказалось (курсор в левом верхнем углу и общее отрицание всего :slight_smile: ). Так что не такое оно пока (ПОКА) и шустрое. Так что пока “пельмени разлепить - мясо на исходную” :slight_smile:

Какие параметры компиляции выставляли и какие опции ядра?

P.S.
Параметры рассчитаны на Desktop или Server и для Low-Latency Desktop не подойдут.

Preemption Model (Voluntary Kernel Preemption (Desktop))  --->
        ( ) No Forced Preemption (Server)
        (X) Voluntary Kernel Preemption (Desktop)
        ( ) Preemptible Kernel (Low-Latency Desktop)

Для Low-Latency Desktop тоже подобраны оптимальные параметры, но разницы между Desktop и Low-Latency Desktop в обычной работе Вы не заметите. Музыка или видеофильм у Вас не прервется на варианте с Desktop даже при полной нагрузке процессоров компиляцией или другими тяжелыми задачами. Главное правильно выставить параметры ядра. У меня процессор в 2 раза медленнее и такого ни разу не произошло после нахождения оптимальных параметров. И плюс в том, что на Desktop варианте производительность выше. Частично мои мысли по этому вопросу изложены тут.

Влез в Makefile, который в /usr/src/linux
и вставил (как было обговорено раньше)

HOSTCFLAGS = -O3 -march=native -mtune=native --param l1-cache-line-size=64 --param l1-cache-size=24 --param l2-cache-size=256 -msahf -mcx16 -mfpmath=387 -fmerge-all-constants -fexcess-precision=fast -fomit-frame-pointer -fno-align-functions -fno-align-loops -fno-align-labels -fno-align-jumps -g0 -Wno-all -pipe

Заранее уточню l1-cache-size=24
и
l2-cache-size=256

При запуске cl-kernel -o -m

единственное, что изменил, это в параметрах процессора отключил два параметра, касающихся AMD и количество ядер уменьшил с 8 до 4. Все. Больше ничего делать не стал специально - для проверки сработает или нет.

При комиляции на всех модулях выдавалось предупреждение, что 387 набор команд отключен, используется расширение sse

Заранее уточню l1-cache-size=24 и l2-cache-size=256

По L2 мы определились более менее точно 256к на процессор. По L1 не могу сказать на 100% что лучше выставлять, так как кеш данных 32к, а кеш инструкций 24к. Что именно подразумевается в gcc под этим мне пока не ясно. Руководства не дают ответа на этот вопрос. В исходном коде gcc лично пока не проверял на что конкретно влияет этот параметр. Так что решай сам. Или попробуй найти в исходном коде функцию, которая обрабатывает этот параметр. В алгоритме разобраться помогу.

Больше ничего делать не стал специально - для проверки сработает или нет.

По умолчанию в ядре calculate выставлен параметр Preemptible Kernel (Low-Latency Desktop). Смени -O3 на -O2. Это должно сработать, если хочешь Low-Latency Desktop. Но рекомендую выставить параметры как я рассказывал по ссылке. Производительность будет лучше.

При комиляции на всех модулях выдавалось предупреждение, что 387 набор команд отключен, используется расширение sse

Попробуй выставить -mfpmath=both или -mfpmath=sse. Ранее нельзя было выставлять эти параметры, но ядро 3.2.0 уже имеет модули с кодом sse. Полная компиляция настроенного ядра на твоем компьютере должна занимать менее 10 минут, что позволяет более менее оперативно поэкспериментировать с параметрами. У меня эта процедура занимает чуть более 20 минут для сравнения. Зато отладив ядро один раз получишь высокопроизводительную систему.

P.S.

Сейчас попробую прогнать компиляцию ядра 3.2.0 с такими опциями:

-O3 -march=native -mtune=native --param l1-cache-line-size=64 --param l1-cache-size=24 --param l2-cache-size=256 -msahf -mcx16 -mmmx -msse -msse2 -msse3 -mssse3 -mfpmath=both -fmerge-all-constants -fexcess-precision=fast -fomit-frame-pointer -fno-align-functions -fno-align-loops -fno-align-labels -fno-align-jumps --param max-unroll-times=4 --param max-unrolled-insns=72 --param max-average-unrolled-insns=216 -funroll-all-loops -fno-gcse -g0 -Wno-all -pipe

О результатах расскажу. Если получишь положительный результат раньше - отпиши пожалуйста.

Ну ядро у меня, насколько я понимаю, 3.1.6
Кэш l1 пока буду считать 24, но все равно- получу устойчивый вариант, можно будет поиграться.
Пока планирую, когда вернусь домой с работы попробовать вариант с

HOSTCFLAGS = -O3 -march=native -mtune=native --param l1-cache-line-size=64 --param l1-cache-size=24 --param l2-cache-size=256 -pipe

Если заработает - начну добавлять. Компиляция занимает порядка часа, так как я же не отключал все неиспользуемые модули (сеть, scsi и т.п.) Ну и еще надо будет полазить по grub.conf, так как сдается мне, что все прописывается не в нем, как я привык в SuSE, а где-то в другом месте. Не хотелось бы попасть в вариант, когда и OLD-ядро и новое - оба неработоспособны.

Просто перед компиляцией резервируй каталог boot - в любой момент можно вернуть без головной боли.

У меня неудача с компиляцией с поддержкой sse - получается больший размер кода, чем при параметре -mfpmath=387.

ld: Setup too big!
make[1]: *** [arch/x86/boot/setup.elf] Ошибка 1
make: *** [bzImage] Ошибка 2

Но очень похоже, что большая часть ядра компилируется с использованием инструкций sse, а часть с использованием сопроцессора 387. Буду еще душить разворот циклов постепенно.

кеш данных 32к, а кеш инструкций 24к

Оговорился. Кеш данных 24к, кеш инструкций 32к.

Вариант с

O3 -march=native -mtune=native --param l1-cache-line-size=64 --param l1-cache-size=24 --param l2-cache-size=256 -pipe
прошел. Ядро собралось и загрузилось. Начну добавлять “сзади” и пересобирать.

Пока попробую

-O3 -march=native -mtune=native --param l1-cache-line-size=64 --param l1-cache-size=24 --param l2-cache-size=256 -mfpmath=both -fmerge-all-constants -fexcess-precision=fast -fomit-frame-pointer -fno-align-functions -fno-align-loops -fno-align-labels -fno-align-jumps -g0 -Wno-all -pipe

Поглядим…

-mfpmath=both или -mfpmath=sse и *-mmmx -msse -msse2 -msse3 mssse3* не прокатывают ядро уходит в перезагрузку.

Этот вариант без осечки:

-O3 -march=native -mtune=native --param l1-cache-line-size=64 --param l1-cache-size=24 --param l2-cache-size=256 -mno-fused-madd -mno-align-stringops -m32 -msahf -mcx16 -mpc32 -fmerge-all-constants -fexcess-precision=fast -fomit-frame-pointer -fno-align-functions -fno-align-loops -fno-align-labels -fno-align-jumps --param max-unroll-times=4 --param max-unrolled-insns=72 --param max-average-unrolled-insns=216 -funroll-all-loops -fno-gcse -g0 -Wno-all -pipe

Но меня все же смущает параметр –param l1-cache-size=24. Может все же 32 нужно устанавливать? Ведь логично было бы предположить, что оптимизация идет по инструкциям, а не по порциям данных, так как этим должен заниматься по идее алгоритм программы, а не оптимизатор. Именно из-за этого я выбирал значение 32. Хотя и тут не уверен. И да… есть еще вопрос. Не нужно ли это значение еще и делить между ядрами, пускай даже и виртуальными?

P.S.

По поводу кеша инструкций L1 оставил 32. Экспериментально выяснил, что разницы между 16к на виртуальное ядро и 32к нет. Результаты теста в пределах погрешности. Вопрос поднимал тут.

Пересобрал с ключами:

-O3 -march=native -mtune=native --param l1-cache-line-size=64 --param l1-cache-size=24 --param l2-cache-size=256 -mno-fused-madd -mno-align-stringops -m32 -msahf -mcx16 -mpc32 -fmerge-all-constants -fexcess-precision=fast -fomit-frame-pointer -fno-align-functions -fno-align-loops -fno-align-labels -fno-align-jumps --param max-unroll-times=4 --param max-unrolled-insns=72 --param max-average-unrolled-insns=216 -funroll-all-loops -fno-gcse -g0 -Wno-all -pipe

Все загрузилось и работает. Теперь два следующих вопроса.

Первый. Я собираюсь установить –param l1-cache-size=32 и попробовать перегенерить Как и чем промерить производительность системы?

Все тем же nbench или еще чем еще?
Второй

Все ключи для ядра автоматом в make.conf? Или m32 и mpc32 лучше убрать?

Первый. Я собираюсь установить --param l1-cache-size=32 и попробовать перегенерить Как и чем промерить производительность системы?

Уже померял. Разницы не заметно совсем. Ставь 32.

Все ключи для ядра автоматом в make.conf?

Не совсем автоматом, дополняем их ммх и sse ключами:

CFLAGS="-O3 -march=native -mtune=native --param l1-cache-line-size=64 --param l1-cache-size=32 --param l2-cache-size=256 -mno-fused-madd -mno-align-stringops -m32 -msahf -mcx16 -mpc32 -mmmx -msse -msse2 -msse3 -mssse3 -mfpmath=both -fmerge-all-constants -fexcess-precision=fast -fomit-frame-pointer -fno-align-functions -fno-align-loops -fno-align-labels -fno-align-jumps --param max-unroll-times=4 --param max-unrolled-insns=72 --param max-average-unrolled-insns=216 -funroll-all-loops -fno-gcse -g0 -Wno-all -pipe"

CXXFLAGS="${CFLAGS}"

Или m32 и mpc32 лучше убрать?

А зачем тебе 64 битное окружение на нетбуке? Получается лишний расход памяти, если оперативки планируешь использовать меньше 8Гб. Да и операции с плавающей точкой на атоме мягко говоря не блещут производительностью из-за больших задержек в конвейере, поэтому выставлено -mpc32.

Вывод: параметры оптимизации для atom n270 и для atom n570 идентичны…

nbench, кстати, индекс работы с памятью снизил с 12 (первые результаты) до 9. Смешно. Что-то не то получилось

Попробуй выкинуть для начала параметры -m32 и -mpc32. У меня тоже небольшое снижение производительности при компиляции nbench с этими параметрами, но не такое заметное.

Оп. Ошибочка - не надо лазить по форуму, когда тест идет, да и пересобрать с ключами не мешало бы. Нормально - те же 12. Теперь ядро с 32К кэша пересоберу - и, думаю, можно будет подумать о “world’е”.