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

sched_setaffinity cpusets taskset google

https://duckduckgo.com/?q=cpu+affinity+arm+linux

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

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

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

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

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

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

setenv bootargs 'isolcpus=0'

printenv

boot

редактирование uEnv.txt не помогает ?
http://unix.stackexchange.com/questions/218846/uboot-passes-arguments-to-kernel

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

Проверь, передался ли параметр:

$ cat /proc/cmdline

В выводе /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

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

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

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

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

setenv bootargs ${bootargs} isolcpus=0
saveenv
bootm

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

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

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

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

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
Теперь мне нужно их заэнаблить и пересобрать имидж?

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

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

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

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

У меня исходники для 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

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

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

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

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

Количество памяти влияет, скорость 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'е, говорят, есть.

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

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

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

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

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

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

swappiness посмотри

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

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

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

Вот тут, скорее всего, твой случай описан. Но ты, наверное, это уже читал.

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

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