что значит пропадает?
если вы отключите smp
то будет работать 1 ядро из 2, причем на том же ядре еще и будет выполняться системная нагрузка, так что вы получите снижение производительности, а насчет потребления энергии - на современных процессорах , если процессор не загружен, то он и не потребляет энергии как при нагрузке

Разве одно ядро работать будет? Хотя, именно сомнения меня и сподвигли на начальный вопрос.

С другой стороны, вот из док от серверов НР

When using the «noapic» boot parameters, an SMP kernel does not use some of the advanced features of the interrupt controller on multi processor machines. When using the «maxcpus=0» or «nosmp» parameters, an SMP kernel on a SMP server will operate in single processor mode.

Что в данном контексте означает single processor mode?

Я проводил эксперименты на обычной десктопной машине, отключал в БИОС всякие ACPI, и однопоточное приложение загружало единственный процессор на 75-80%, при включенном же SMP нагрузка на процессор не поднималась выше 50% по версии top. То, что приложение сидело на одном ядре, хорошо видно было в htop. В нужном же сервере отключить многоядерность невозможно.

[quote]если вы отключите smp то будет работать 1 ядро из 2[/quote] Вот опять же выдержка

nosmp      [SMP] Tells an SMP kernel to act as a UP kernel, and disable the IO APIC. legacy for «maxcpus=0».

если ты отключишь smp, система перестанет видеть второе ядро

смысла в этом не вижу никакого

> при включенном же SMP нагрузка на процессор не поднималась выше 50%

Не на процессор, а на сервер. Смотри в top не вверх, а в процессы.

Хорошо, а что делать с вышесказанным про юнипроцессорное ядро? Юнипроцессорное ядро использует весь процессор, или только одно его ядро? Какие достоверные способы проверки существуют?

>Не на процессор, а на сервер. Смотри в top не вверх, а в процессы. С таким же успехом можно смотреть в htop. В данном контексте я хотел сказать, что смотрю на весь процессор, независимо от количества ядер. Юнипроцессорное ядро использует весь процессор (все ядра), или нет. Ну или можно пойти другим путем - кто подскажет, каким образом заставить однопоточное приложение утилизировать всю вычислительную мощность процессора, независимо от количества ядер.

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

graphite из gcc >=4.4 в некотрых случаях может помочь.

>graphite из gcc >=4.4 в некотрых случаях может помочь.

Приложение не я собираю. Похоже, я в пролете. Проще пошукать на помойке старенький одноядерный 3.6 камень, чем смотреть, как Зион 5130 @2.00GHz в носу ковыряется, вместо работы, при этом проигрывая в производительности простому четвертому пеньку.

оно слабо паралеллит, даже icc -parallel
хотя да, можно где-то до 3% кинуть на другое ядро еще

Ходили слухи, что на ООо или фф есть.
Ес-но если в самой совтине не заложена поддержка, что-то распараллелить сложно, вероятность удачных циклов невелика. А вот напр. imagemagik, собранный с gomp, у меня успешно утилизировал оба ядра.

если ты отключишь smp, система перестанет видеть второе ядро

я, воможно, ошибаюсь, но с включенным smp ядро сможет задействовать более одного ядра для своих нужд, а для программ оно будет предоставлять столько ядер, сколько есть. Очень может быть что я неправ. Поправте, если кто в теме.

я бы автору посоветовала вот что, отключить планировщик задач для вашего процесса, следовательно дать ему полный realtime

загружаетесь, прибиваете все системные процессы к 1-му ядру , к нему же будут прибиты и обработчики irq

schedtool -a 0x1 <список pid>

как вариант можно в inittab запускать первый скрипт инициализации через
schedtool:

пример (Gentoo)
l0:0:wait:/sbin/rc shutdown
l0s:0:wait:/sbin/halt -dhp
l1:1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot

/sbin/rc меняете на /usr/sbin/schedtool -a 0x1 -e /sbin/rc

после этого вся система у вас работает на первом ядре.

запускаете ваш процесс, если от рута то

schedtool -a 0x2 -F -p 99 -n -20 -e <путь>

если он уже запущен , то ставите на уже запущеный pid

schedtool -a 0x2 -F -p 99 -n -20 <PID>

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

+ по возможности оптимизируйте и само приложение
пересоберите под архитектуру с -march=native , желательно с profile guided optimization

Оптимизировать не получится, это сервер контры:сорс :) Чудесным образом помогло рт-ядро и nice -99 для процесса. Утилизированы оба ядра.

http://css.net-alliance.ru/images/util.png

Картинка 5 килобайт, не знаю, как вставить прямо в сообщение.

у вас просто «размазан» процесс по ядрам,
на самом деле в таком варианте производительность может быть ниже

Именно размазывания процесса по ядрам я и добивался. До этого процесс сидел на одном ядре и стабильно грузил его на 100%. Судя по всему, процессу прилично не хватало вычислительной мощности одного ядра. Само собой, что все весьма субъективно, но игрокам пока так больше нравится. Вот только не очень хорошо понимаю физику процесса, это удручает :(

так процесс дальше 1 ядра и не прыгнул, там просто переброска идет

20 мс (допустим, точный интервал задается при компиляции или через /proc) работает на 1 ядре, дальше перекидывается на другое и 20 мс работает там, т.е. результат такой же как и на 1 ядре был, может быть даже хуже из-за обнуления кеша инструкций

> Именно размазывания процесса по ядрам я и добивался.

Объясни, зачем?

До этого процесс сидел на одном ядре и стабильно грузил его на 100%.

Если приложение однопоточное, то это нормальная практика.

Судя по всему, процессу прилично не хватало вычислительной мощности одного ядра.

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

При «размазывании» процесса по ядрам производительность понижается на несколько процентов.

Можно вывод top после нажатия цифры 1?

>Можно вывод top после нажатия цифры 1?

На скриншоте он именно такой и есть :)

и что, стало лучше что ли? для повышения производительности процессы вообще-то принято привязывать к ядру (ядрам) конкретному, а не размазывать....

кстати htop там показывает несколько тредов у программы )

Конечно не стало, по топу это видно.

Вы чего-то совсем не понимаете, наверное.
Для любой операционной системы, 1 CPU == 1 ядро. То есть, многоядерный процессор (включая «виртуальные» ядра гипертридинга) она будет видеть как многопроцессорную систему с соответствующим количеством процессоров.

Таким образом, какой-нибудь 4-х ядерный Xeon с поддержкой Hyper Threading будет распознаваться как многопроцессорная система с 8-ю процессорами.

ОС _может_ понимать, что «на самом деле чип один»: за это отвечают флаги «cpu cores» и «core_id» (см. cat /proc/cpuinfo), тем не менее, отдельные ядра в этом чипе будут использоваться как РАЗНЫЕ процессоры.

Заставить однопоточную программу работать одновременно на нескольких CPU невозможно (ну как минимум, она должна быть откомпилирована с возможностью поддержки многопоточности... да и то, несерьезно это).

Таким образом, отключать SMP вам НЕ ЖЕЛАТЕЛЬНО: ядро автоматически распределяет обработку прерываний («cat /proc/interrupts»), ядерных процессов, других запущенных процессов максимально эффективно. Таким образом, вероятнее всего, ваша программа исполняется на одном CPU, а весь остальной софт - на другом.

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

"однопоточное" ? нет!

вообщем судя по обрезку скриншота htop
сервер КС имеет минимум 3 треда, да, скорее всего 1 тред из них делает максимум работы и грузит максимум от _ОДНОГО_ ядра, заставить его использовать больше - нереально, никакими настройками ядра, никакими патчами к нему, возможно эвристическое (компиляция с Graphite) или OpenMP (исходного кода) распаралелливание на несколько процессоров, но это не в вашей власти.

Сейчас сервер у вас не сьедает ваш процессор полностью, или производительность лимитирована 1 ядром, другие же треды выполняют мелкие вспомогательные функции, но могут (!) выполняться и на другом ядре, так что вы можете получить в htop такую картину -
основной процесс ест 100% одного ядра, другие процессы едят несколько % нагрузки но уже на другом ядре, т.е. суммарная утилизация будет чуть выше 100%

Также не забывайте про то что система тоже кушает процессор, в частности на обработку irq, мой совет про schedtool остается в силе.

Так виднее, что из себя представляет сервер?

http://css.net-alliance.ru/images/htop.png

Я отчетливо понимаю, что htop в качестве измерителя плохой советчик :) Но, разница в поведении игрового сервера есть. Хотя это тоже могут быть иллюзии, в ИТ эффект плацебо силен, как нигде :) К сожалению, не на чем провести полноценные тесты производительности, я обязательно воспользовался бы советом про schedtool. Этот сервер практически под круглосуточной нагрузкой.

Лично мне одно ясно, что нихрена ничего не ясно.

ну вот, вам там есть что раскидывать по ядрам, сервер ts еще висит
хотите отключить smp и чтобы все это работало на 1 ядре?) не смешите)

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

насчет того что лучше серверное ядро или с rt патчами - смотрите сами,
для lineageII например лучше preempt rt

Чтобы минимизировать потерю CPU Time для однопоточного приложения, привяжите его процесс taskset-ом, это можно сделать автоматическим при помощи getpid и cron. А выключать SMP не надо.

>привяжите его процесс taskset-ом

или schedtool

>Заставить однопоточную программу работать одновременно на нескольких CPU невозможно

Хорошо, подойду с другой стороны. С обычным SMP ядром я хорошо видел узкое место - одно ядро было загружено на 100%, это было причиной микролагов, дропов кадров, отправляемых клиенту, неточностью обсчета хитбоксов. Сейчас, с рт-ядром я не вижу узкого места, но оно есть (как суслик)? Как его определить? Еще, производительность не синоним скорости. Игровой сервер имеет массу взаимосвязанных параметров, и их несогласованность может порождать гораздо более негативные последствия, чем более медленная, но согласованная обработка задач. Разумеется. это уже отход от первоначального вопроса, но конечной целью моих изысканий является стабильная работа игрового сервера, но и от понимания теории процессов я сильно-сильно не откажусь. В любом случае спасибо всем за просветительскую работу.

>хотите отключить smp и чтобы все это работало на 1 ядре?) не смешите)

А я ночью то попробовал, общая загрузка составила порядка 95% в пике (начало раунда). Реально то наверняка было 100%, просто лаг самого htop. Тимспик к ресурсам не требователен, его, мне кажется, даже на калькуляторе запустить можно. Посмотрю пока в такой конфигурации. Вообще сервер работал без нареканий с полгода, а последний месяц жалоб стало больше. Диагностика затрудняется еще и тем, что лаги большей частью являются следствием того, что ростелекомовский рутер давится. Большое спасибо всем за информационную поддержку :)

А разве taskset не входит в shedutils?

taskset - util-linux(-ng)
schedtool - schedtool http://freequaos.host.sk/schedtool



taskset управляет только привязкой к ядрам
schedtool дополнительно может выставлять nice, и планировщики
(SCHED_IDLE, SCHED_BATCH, SCHED_NORMAL, SCHED_ISO (только для -ck/bfs!),
SCHED_RR, SCHED_FIFO)

Спасибо... schedutils уже похоронить, оказывается, успели.

heil0@arbeiter:~$ aptitude show schedutils Нет в наличии или подходящей версии для schedutils Пакет: schedutils Состояние: не реальный пакет Предоставляется: util-linux