Так из ОЗУ должен браться по идее кеш... для любых устройств.UAVpilot писал(а):Мысль №2: У дешёвых HDD хоть какой-то кэш, но есть, а у дешёвых SSD как правило нет никакого. В итоге обмен идёт небольшими порциями, что приводит к более частым "перезапускам" DMA.
А данные с диска в ОЗУ разве не надо сначала перенести?..SVP писал(а):Так из ОЗУ должен браться по идее кеш... для любых устройств.
Вот этим DMA и занимается...
SSD это совсем не HDD и требует оптимизацииgoing писал(а):Сегодня сменил SSD на старенький HDD (2003 г.в.) и заметил неожиданный эффект. Латенси тест улучшился, не на много, но улучшился. Был на SSD 13600-14000, а стал 13080. Условия теста одинаковые.
SSD- Silicon Power sata3 S55 60Gb
HDD - Sagate 80Gb
Какие мысли по данному факту ??
Код: Выделить всё
cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]
Код: Выделить всё
sudo echo anticipatory | sudo tee /sys/block/sda/queue/scheduler
Код: Выделить всё
sudo cp /etc/fstab /etc/fstab.bak
Код: Выделить всё
gksu gedit /etc/fstabКод: Выделить всё
#UUID=xxxx-xxxx-xxxx-xxxx none swap sw 0 0
Код: Выделить всё
tmpfs /var/log tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0
tmpfs /var/lock tmpfs defaults 0 0
Код: Выделить всё
/dev/sda1 / ext4 defaults,discard,noatime,nodiratime 0 0Код: Выделить всё
UUID=xxxx-xxxx-xxxx-xxxx / ext4 defaults,discard,noatime,nodiratime 0 0Код: Выделить всё
sudo update-initramfs -u -k allКод: Выделить всё
sudo echo deadline > /sys/block/sda/queue/scheduler"ЛИНУХ" не пахнет, значит свежий.glaz писал(а):3) если линух не свежий, то обязательно опции монтирования диска в fstab (noatime,discard)
Код: Выделить всё
:~> df
Файловая система 1K-блоков Использовано Доступно Использовано% Cмонтировано в
/dev/sda3 35923840 13570088 21275076 39% /
devtmpfs 4046260 0 4046260 0% /dev
tmpfs 4052736 148 4052588 1% /dev/shm
tmpfs 4052736 2088 4050648 1% /run
tmpfs 4052736 0 4052736 0% /sys/fs/cgroup
tmpfs 4052736 40 4052696 1% /tmp
/dev/sdc3 25066604 6928592 17072032 29% /usr/src
/dev/sdc8 2030736 1320120 589412 70% /var
tmpfs 4052736 179708 3873028 5% /var/tmp
/dev/sdc7 150191412 68313052 80792936 46% /home
Код: Выделить всё
:~> cat /etc/fstab
UUID=b1cb6cc3-a603-40f8-b224-1b697b432097 / ext4 noatime,acl,user_xattr,discard 1 1
UUID=534e7bc5-9aae-48b9-826b-709cad12d443 /usr/src ext4 noatime,acl,user_xattr 1 2
UUID=2391fa38-b480-41c5-b645-1230302ac184 /home ext4 noatime,acl,user_xattr 1 2
UUID=812e28f6-97d6-42f9-b643-4ccd3e4ba056 /var ext4 acl,user_xattr 1 2
UUID=2cd26810-b8e9-4d1b-ac89-3a4b6615cc2b swap swap defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 01- Памяти как видите достаточно, но отключать swap не намерен ( мешают религиозные убежденияglaz писал(а):1) если памяти достаточно - то можно отключить swap, если нет то тем менее изменить агресивность его использования.
2) время отложенной записи на диск
3) если линух не свежий, то обязательно опции монтирования диска в fstab (noatime,discard)
4) подобрать i/o планировщик: https://www.opennet.ru/base/sys/linux_s ... s.txt.html
etc ..
) даже при условии, что система его не использует вообще.Код: Выделить всё
:~> dmesg | grep scheduler
[ 0.770782] io scheduler noop registered (default)
[ 0.770784] io scheduler deadline registered
[ 0.770820] io scheduler cfq registered
Вообще без разницы. очерёдность аргументов ядра никакой роли не играет.going писал(а):В командной строке параметров загрузки ядра две команды стояли в разных местах. "...... nomodeset isolcpus=2 ...." , " .... isolcpus=2 nomodeset ....".
Первый вариант показывает лучшие результаты.
С точки зрения RT в системе это время не важно. Нас волнует только время занятости таких ресурсов как память, процессор, шина между ними.glaz писал(а):У вас если sdc жесткий диск, то обращение к нему будет долгим - io операция займет продолжительное время.
То есть впрямую это зависит от размера блоков, передаваемых по DMA?UAVpilot писал(а): DMA запрашивает захват шины памяти, захватывает шину как только это становится можно и начинается передача данных от контроллера (из кэша) в память - именно на этот момент занимается критичный для RT ресурс
Я то же так думал, но факт того что очерёдность применения параметров командной строки в этом конкретном случае имеет значение зафиксировал.UAVpilot писал(а):Вообще без разницы. очерёдность аргументов ядра никакой роли не играет.
А с каким приоритетом работает таймер? Хотелось бы разобраться в этом вопросе. Например если таймер высокого разрешения самой материнки использовать?Сергей Саныч писал(а):Опять же, есть зависимость от приоритетов прерываний - если какой-то драйвер начинает обрабатывать свое прерывание на приоритете, высшем, чем прерывание от таймера, синхронизирующего RT, то это может сильно влиять на Latency.
Вот бы узнать! По идее, должен с наивысшим, а как на самом деле - вопрос отдельный.going писал(а):А с каким приоритетом работает таймер?
Сергей Саныч писал(а):Материнка была где-то 2000-2002 года, кажется, EPOX, на чипсете вроде бы VIA. Процессор - Athlon XP 1700 или около этого. Видео Radeon 9600 или что-то похожее, но тоже десятилетней давности. Путем научного шаманства - залез в BIOS setup, в разделе PNP/PCI Setting нашел пункт вроде VGA Interrupt Enable и запретил его. После чего Latency упал примерно с 200000 до 12000-15000.
Да, но RT сиситема и в этот процесс вмешивается - ограничивает максимальный размер блока...Сергей Саныч писал(а):То есть впрямую это зависит от размера блоков, передаваемых по DMA?
Подобные приёмы работы с прерываниями справедливы для каких-нибудь несложных программ для микроконтроллеров, но не для задач типа "ядро RT ОС". Например как некий драйвер будет обрабатывать своё высокоприоритетное прерывание, если шина доступа к памяти занята и процессор даже не может считать программный код обработчика прерывания?..Сергей Саныч писал(а):Опять же, есть зависимость от приоритетов прерываний - если какой-то драйвер начинает обрабатывать свое прерывание на приоритете, высшем, чем прерывание от таймера, синхронизирующего RT, то это может сильно влиять на Latency.
Это "погрешности измерения". Все параметры ядра оказываются в одном общем массиве, в котором каждый компонент ядра ищет свои параметры, которые знает в том порядке, в котором ядро эти компоненты вызывает/запускает.going писал(а):Я то же так думал, но факт того что очерёдность применения параметров командной строки в этом конкретном случае имеет значение зафиксировал.
У самого ядра есть параметры. У каждого модуля есть свои параметры. Частенько их интересы пересекаются. Как быть ядру в таком случае? Думаю существует внутренняя логика. Наверное от порядка поступления и применения параметров в командной строке что то должно зависеть. К тому же в этот момент ядро и модули с параметрами по дефолту уже загружены. Или я ошибаюсь?UAVpilot писал(а):Это "погрешности измерения". Все параметры ядра оказываются в одном общем массиве, в котором каждый компонент ядра ищет свои параметры, которые знает в том порядке, в котором ядро эти компоненты вызывает/запускает.
Их интересы пересекаться не могут т.к. ядро в Linux "монолитное".going писал(а):У самого ядра есть параметры. У каждого модуля есть свои параметры. Частенько их интересы пересекаются. Как быть ядру в таком случае? Думаю существует внутренняя логика. Наверное от порядка поступления и применения параметров в командной строке что то должно зависеть. К тому же в этот момент ядро и модули с параметрами по дефолту уже загружены. Или я ошибаюсь?
The following is a consolidated list of the kernel parameters as implemented
(mostly) by the __setup() macro and sorted into English Dictionary order
(defined as ignoring all punctuation and sorting digits before letters in a
case insensitive manner), and with descriptions where known.
Описание синтаксиса применения параметров не более. Описания как они сочетаются друг с другом очень мало.UAVpilot писал(а):Вот, даже исходники изучать не надо:
https://git.kernel.org/cgit/linux/kerne ... s/v3.4.110
Правильно не могут. Поэтому ядро при возникновении такой ситуации просто игнорирует какой то из параметров. Вопрос какой? По какому критерию?UAVpilot писал(а):Их интересы пересекаться не могут т.к. ядро в Linux "монолитное".