LINUX.ORG.RU

Оптимизация работы ядра

 


0

4

Имеется Ubuntu под 2-х ядерный ARM, есть потребность в оптимизации загрузки процессора. Возможно ли обеспечить разделение задач (процессов) по ядрам, чтобы одни процессы висели на одном ядре, а другие на другом соответственно? Если это реализуемо, то присоветуйте в какую сторону копать...


sched_setaffinity cpusets taskset google

anonymous
()

Спасибо за инфу! Удалось распределить запущенные процессы между ядрами при помощи taskset. А вот распределить во время загрузки системы не смог. Во всех постах описывается метод isolcpus=<CPU_ID> для GRUB, но в ARM используется другой загрузчик. Как сделать?

Oxff
() автор топика
Ответ на: комментарий от Oxff

пофиг гроб или нет. Это параметр ядра который передаётся ему загрузчиком. Передавай этот параметр своим загрузчиком. Как исчи в мануале к своему загрузчику.

FFSinit ★★
()

В моей системе используется U-Boot, не нашел чтобы где-то описывалось как можно передавать параметр isolcpus.

Oxff
() автор топика
Ответ на: комментарий от Oxff

не нашел чтобы где-то описывалос как можно передавать параметр isolcpus.

а ты ищи как передавать параметры ядру, а не конкретно про isolcpus. неужели непонятно?

teod0r ★★★★★
()

Нашел как вносить изменения в конфиг u-boot, но разделение между ядрами не произошло. Прервал u-boot загрузку и задал параметры слудующим образом:

setenv bootargs 'isolcpus=0'
Проверил изменения окружения
printenv
и загружаемся
boot
Что дальше делать не пойму.

Oxff
() автор топика
Ответ на: комментарий от Deleted

Спасибо, но uEnv.txt в системе (Linux 3.4.112-sun7i) не нашел. Тут http://linux-sunxi.org/UEnv.txt описывается как его смонтировать из NAND памяти, вот только нет у меня на борту NAND памяти, система грузится с MMC.

Oxff
() автор топика
Ответ на: комментарий от anonymous

В выводе /proc/cmdline параметра isolcpus=0 не наблюдаю. Однако из командной строки u-boot printenv показывает что isolcpus=0 присутствует. А может быть что параметр bootargs игнорируется системой?

console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4
cgroup_enable=memory swapaccount=1 sunxi_ve_mem_reserve=0
sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0
disp.screen0_output_mode=1920x1080p60 panic=10 
consoleblank=0 enforcing=0 loglevel=1

Oxff
() автор топика
Ответ на: комментарий от Oxff

Если ядро грузится с использованием fdt(Flattened Device Tree)(а оно должно), то раньше у u-boot была связанная с этим особенность. Ядро брало bootargs из загруженного в память fdt образа, а u-boot передавал bootargs каким-то старым методом. В этом случае передать ядру параметры можно было только изменив bootargs в загуженном в память образе fdt через fdt set /chosen bootargs.

anonymous
()
Ответ на: комментарий от Oxff

В выводе /proc/cmdline параметра isolcpus=0 не наблюдаю

Значит до ядра не дошло. Тебе надо точно узнать как передавать параметры ядру из u-boot.

anonymous
()
Ответ на: комментарий от Oxff

Везде ещё советуют всё это записывать на флеш с помощью saveenv. То есть вот такую последовательность:

setenv bootargs ${bootargs} isolcpus=0
saveenv
bootm

Но ты разберись хорошенько, чтобы не окирпичить девайс.

Тут читал? http://www.denx.de/wiki/view/DULG/LinuxKernelIgnoresMyBootargs

Кстати, поговаривают, что uEnv.txt лежит в /dev/nanda и этот раздел надо сначала смонтировать.

anonymous
()
Ответ на: комментарий от anonymous

Так и делал.
Спасибо за ссылку, тут как раз описывается моя трабла.

This problem is typical for ARM systems only. The following discussion is ARM-centric: First, check to ensure that you have configured your U-Boot build so that CONFIG_CMDLINE_TAG is enabled. (Other tags like CONFIG_SETUP_MEMORY_TAGS or CONFIG_INITRD_TAG may be needed, too.) This ensures that u-boot will boot the kernel with a command-line tag that incorporates the kernel options you set in the «bootargs» environment variable.

В исходниках нашел файлик u-boot.cfg, видимо это и есть конфиг для u-boot.
Сколько я понимаю эти определения не установлены в enabled.
#define CONFIG_CMDLINE_TAG
#define CONFIG_SETUP_MEMORY_TAGS
#define CONFIG_INITRD_TAG
Теперь мне нужно их заэнаблить и пересобрать имидж?

Oxff
() автор топика
Ответ на: комментарий от Oxff

Скорее у тебя второе, так как в исходниках я не нашёл u-boot.cfg, а только платформозависимые *.cfg. Твой файл, скорее всего, содержит опции, которые были включены при компиляции, типа /proc/config.gz в ядре и с ним уже ничего не сделаешь.

Если это так, то надо копать исходники ведра для своей борды. Тебе надо найти в исходниках u-boot куда он кладёт параметры именно для твоей архитектуры и затем добавить строку BOOT_PARAMS(<твой адрес>) в блок макроса MACHINE... в ядро, как там написано. Если BOOT_PARAMS уже есть, то надо проверить, правильно ли там записан адрес.

Пересобрать, залить кипятком, дать настояться. Употреблять строго по мерной ложечке во избежание побочных эффектов :)

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

anonymous
()
Ответ на: комментарий от anonymous

У меня исходники для ARM платформы. Вот листинг дир.sources/u-boot/

api        drivers   MAINTAINERS      System.map      u-boot.img
arch       dts       MAKEALL          test            u-boot.lds
board      examples  Makefile         tools           u-boot.map
cmd        fs        net              u-boot          u-boot-nodtb.bin
common     include   post             u-boot.bin      u-boot.srec
config.mk  Kbuild    README           u-boot.cfg      u-boot-sunxi-with-spl.bin
configs    Kconfig   scripts          u-boot.dtb      u-boot.sym
disk       lib       snapshot.commit  u-boot-dtb.bin
doc        Licenses  spl              u-boot-dtb.img
Сейчас пробую пересбрать весь имидж с изменениями в CONFIG_CMDLINE_TAG.

Oxff
() автор топика
Ответ на: комментарий от Oxff

Такой вопрос, кроме процессов что-то еще влияет на работу стабильную ядра (например Kernel, syscalls, irq и т.д..)? И как проверить на каких ядре/ядрах крутятся процессы?

Oxff
() автор топика
Ответ на: комментарий от Oxff

Получилось с параметром?

что-то еще влияет на работу стабильную ядра

А что не устраивает?

Количество памяти влияет, скорость IO и свопа в частности сильно влияет на производительность системы. Можно попробовать планировщик поменять на BFQ, например или включить blk-mq, опять же, через параметр ядра scsi_mod.use_blk_mq=1. На SSD рекомендуют использовать NOOP.

swappiness посмотри. Левые процессы влияют, которые отжирают ЦП, память и IO — убить всех!

Если рамы много, то /tmp можно в tmpfs сделать. Если процесс агрессивно пишет на хард, то тоже можно его данные в tmpfs перекинуть, по возможности. Логи, там, всякие, кеши. Ещё можешь noatime для харда включить.

Приоритет своим задачам повысь. man renice, chrt, sched. Про taskset ты уже в курсе.

как проверить на каких ядре/ядрах крутятся процессы?

С нормальным ps это можно так сделать:

$ ps -eLo user,pcpu,vsz,rss,cls,pri,ni,nlwp,psr,ppid,pid,tid,s,cmd --headers

USER     %CPU    VSZ   RSS CLS PRI  NI NLWP PSR  PPID   PID   TID S CMD
root      0.0 114716  5292  TS  19   0    1   0     0     1     1 S /sbin/init
root      0.0      0     0  TS  19   0    1   2     0     2     2 S [kthreadd]
root      0.0      0     0  TS  19   0    1   0     2     3     3 S [ksoftirqd/0]
root      0.0      0     0  TS  39 -20    1   0     2     5     5 S [kworker/0:0H]
root      0.0      0     0  TS  19   0    1   3     2     7     7 S [rcu_preempt]
root      0.0      0     0  TS  19   0    1   7     2     8     8 S [rcu_sched]
root      0.0      0     0  TS  19   0    1   0     2     9     9 S [rcu_bh]
root      0.0      0     0  FF 139   -    1   0     2    10    10 S [migration/0]
...

Столбцы:

USER — пользователь, запустивший процесс
%CPU — загрузка ЦП в %
VSZ  — виртуальная память в кБ
RSS  — резидентная память в кБ
CLS  — политика планировщика процессов
PRI  — приоритет
NI   — значение найс
NLWP — количество потоков процесса
PSR  — номер процессора, на котором выполняется процесс или поток
PPID — ID родительского процесса
PID  — ID самого процесса
TID  — ID потока (LWP)
S    — статус процесса
CMD  — команда с аргументами

Но у тебя там, скорее всего, busybox и там надо как-то по-другому это делать, потому, что вот это на моём busybox'е (версия 1.24.1 на Арче) не работает и даже по документации не работает :(

В списке столбцов top'а тоже нет psr. В htop'е, говорят, есть.

Вот ещё способ, который будет везде работать, но он неудобный.

anonymous
()
Ответ на: комментарий от anonymous

Спасибо ценную инфу!

Получилось с параметром?

Ядра изолировал, но иначе, нужно править boot.cmd и затем его переконвертить в boot.scr.

А что не устраивает?

Не достаточный уровень, оптимизации ядра.

swappiness посмотри

Уже закэширован на tmpfs

Но у тебя там, скорее всего, busybox

Нет, полноценный пакет, но под ARM
С узермодными процессами все замечательно, но когда дело касается работы Kernel-а, т.е. различные системные ф-ми то изолированное ядро начинает молотить.
Немного поясню задачу, мне нужно максимально (в идеале на 100%) изолировать работу одного конкретного драйвера от всех остальных процессов, включая сам Kernel, прерывания, кэширование, и все прочее.. В общем работу драйвера ничего не должно отвлекать.
Правда, до конца не понимаю возможно ли работу конкретного драйвера подвесить на одно ядро, а Kernel на другое?
Да можно ли сам Kernel изолировать на одном ядре...?

Oxff
() автор топика
Ответ на: комментарий от Oxff

если поддерживается виртуализация гугли jailhouse

anonymous
()
Ответ на: комментарий от anonymous

Респект!
Еще конечно нужно потестить, но фича работает)

Oxff
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.