sbrk() в современных системах не используется, используется mmap()

Почему-почему...

Перекидываем что-нибудь жирное с ssd на допотопную USB 2.0 флешку. Естественно, данные считываются с ssd в память быстрее, чем пишутся на тормозную флешку. Если данных действительно много, они все не влезут в объем памяти, заданный параметром vm.dirty_ratio, который по-умолчанию равен 40% от объема памяти (предположим, у нас ее не больше 8 гигабайт). Возрастает iowait. Система зависает.

Потому что в данном случае вообще непонятно из Вашего описания как там собрано ядро и какой планировщик ввода-вывода там выбран (io scheduler). Я бы рекомендовал для Вашего случая (USB-flash + SSD) такой планировщик как noop. Для такого рода девайсов, а так же для RAID-массивов со своим контроллером как раз.

Дальше не ясно как у Вас собрана модель вытеснения (preemptive mode). Для серверов выгоднее дать заканчивать операцию и переходить к другой, т.е., no-preemptive. Для «десктопов» этот вариант не пойдёт, равно как и low-latency desktop тоже.

Дальше не ясно как часто ядро дёргают за «тестикулы» на предмет обслуживания прерываний… В общем, 1000 раз уже говорено и ещё раз могу повторить. Пересоберите ядро. Руками и при включённом мозге.

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

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

Угу. А ещё линукс и очень дружелюбная система. Только друзей себе подбирает крайне избирательно.

И как обычно никто не хочет этим заниматься, никто не помнит как это устроено, поэтому давайте это все просто выкинем…

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

Ты это… Как бы помягче сказать… Странный.

Да что угодно говорить можно.

Ты это… Как бы помягче сказать… Странный.

«Мешки ворочать» и… «говорить» (ну, Вы поняли) материи суть разные. Почему-то всё таки, проблем не наблюдаю.

Хотелось бы узнать Ваше наипросвящённейшее мнение как так получается – у системы ресурсов достаточно, а использовать она их не может? И почему же УМВР?

Повезло.

Видимо потому, что пересобираю ядра под нужные на данном хосте задачи?

Отличное решение, так победимЪ!

А потом горят от шуток про 2% facepalm

Все целиком при этом не повисло?

Потому что в данном случае вообще непонятно из Вашего описания как там собрано ядро и какой планировщик ввода-вывода там выбран (io scheduler). Я бы рекомендовал для Вашего случая (USB-flash + SSD) такой планировщик как noop. Для такого рода девайсов, а так же для RAID-массивов со своим контроллером как раз

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

планировщик ввода-вывода там выбран (io scheduler)

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

Дальше не ясно как у Вас собрана модель вытеснения (preemptive mode). Для серверов выгоднее дать заканчивать операцию и переходить к другой, т.е., no-preemptive. Для «десктопов» этот вариант не пойдёт, равно как и low-latency desktop тоже

В арче по дефолту ядро собирается с preemptive. Его и использую.

Ну если ты тиринг побеждаешь пересборкой ядра, то тут уже всё… My name is Giovanni Giorgio.

Мне 16 ГБ ОЗУ не хватало. При ничего не запущенного (3 ГБ ОЗУ примерно занято) — тормозило гуй нормально при копировании на медленную флешку.

Ну, может у него еще больше памяти. Или ты копировал больший объем данных. Или твоя флешка медленней. В том-то и прикол, чтобы воспроизвести 12309, нужно соблюсти определенные условия. По этому, одни совершенно честно говорят «все пучком!», другие настолько же честно отвечают «кошмар, все повисло нафиг!».

Даже не тормозило, говорю же.

Ну, dd пишет прямо на устройство, если не ошибаюсь. Он ничего в памяти не кеширует. 12309 связан с кешированием.

если не ошибаюсь

Или ты, или я. Не будет кешировать, только если флаг выставить. К тому ещё чтение есть.

Нет.

Повезло.

Никакого «везения». Генточка. И понимание того, что дефолтное ядро с массой ненужных на данном конкретном хосте вещей это зло. Ядро из liveusb это не более чем ядро для запуска «где угодно». В остальном все подразумевают что ядро будет пересобрано для данного конкретного хоста по месту.

Да уже победили...

Отличное решение, так победимЪ!

Если Вы ещё не заметили, то посмотрите на всё громадьё линуксов вокруг. Начиная от CPE у Вас дома (домашний роутер) и кончая чем угодно, включая даже пару ОС для мобил.

Мне теперь просто интересно (после выхода M$-Linux) сколько в новой винде будет именно от винды, а сколько от линуксов.

Так что, «пришла беда победа откуда не ждали». =))) Внезапно. Виндокапец состоялся тихо и негромко. Без объявления войны. =)))

А потом горят от шуток про 2% facepalm

У меня? Нет. Не горит. Я вообще-то, рад этому. Людей, которые занимаются всякой эмбеддерщиной и прочим, быть много не должно. А у них как раз с Linux всё хорошо. Это и есть те самые 2% (по большому счёту), которые обеспечивают основную массу индустриальных решений для пользователей.

И меня не оставляют сомнения в том, что игорей в Linux сознательно не завозят. Чтобы не отвлекать от трудов праведных. На моей памяти разве что EVE-Online была с нативным линуксовым клиентом года где-то до 2004го. Потом как отрезало.

А пользователи… Ну для них есть та же «трофейная» винда. Не может человек собрать себе систему, да пусть не собирает. Есть та же ChromeOS, в девичестве Gentoo, которую каждый производитель Chrome Book гнёт по-своему. Там цена толковой сборки уже вбита в цену железки. Не может собрать – пусть платит и не парится.

Ни кто не против. Ну и да. Если честно, то я не помню когда Linux ставил перед собой целью завоевать рынок коммерческого десктопа. И, повторю, я эту цель считаю и абсурдной и вредной.

Не уверен.

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

Если исходить из того, что работа идёт SSD+USB, то BFQ или иной io scheduler для HDD здесь не нужен как раз. Проблема в том, что планировщики такого рода нужны чтобы вращающиеся шпиндели и перепозиционирующиеся головки учесть и задержки, которые из-за этих процессов возникают.

Для SSD, NVRAM, USB всего этого ненужно. Там ни что ждать ненужно. На RAID-массивах с аппаратным контроллером тоже – система туда просто скидывает данные, вот и всё.

В арче по дефолту ядро собирается с preemptive. Его и использую.

Лады. Ясно. Посмотрите ещё параметр Timer frequency. 1000Hz может оказаться слишком маленьким интервалом опроса, а 100Hz слишком крупным.

Ну и что там ещё понапихано из того, чего у Вас на Вашем реальном железе нет.

Ладушки...

My name is Giovanni Giorgio.

Теперь я знаю как Вас звать. А то всё «понь», да «понь»… =)))

Извините, не удержался. =)))

Ну если ты тиринг побеждаешь пересборкой ядра, то тут уже всё…

А тиринг это одно из проявлений 12309. Видимых. Это для случая, когда юзер конченный уже сидит и орёт «Ааааа! Гавно ваш линукс! Вон, всё на экране поплыло!!!11адын-адын».

А на деле просто системе вывода на экран (как правило, композитору) не хватило ресурсов. Тех же тактов процессора. Т.е., начался вывод отрабатываться, а потом херак, что-то пошло не так и графон начал отрабатывать вывод с чуточку другого места, с пропуском. И поэтому отдельные «умники» рекомендуют, например, убрать вертикальную синхронизацию. Иногда. Т.е., в системе полное говно, но мы решили почистить себе ботинки, ага… Во-время. И к месту.

Т.е., посмотреть что там собирается в дефолтном ядре (не исключено что открытые дрова на нвидию, интел, AMD, всё и в куче) это сложно. Собрать систему так, чтоб отдельные подсистемы дополняли друг-друга, а не конкурировали бы за ресурсы, это так же сложно. А вот смотреть на тормоза xfce на AMD (например) или на тормоза дров NVidia (проприетарных!) это нормально.

Ну будет процесс в цикле ждать страницу, что изменится?

напиши в рассылку kernel.org, мы все с удовольствием почитаем

Повезло.

это другое. они же висят в памяти и дергают медленную флешку

что за простыню я прочёл?

Видимо потому, что пересобираю ядра под нужные на данном хосте задачи?

на копирование флешки одно ядро, а для просмотре ютюба перезагружаться в другое ядро? ты угараешь?

такой планировщик как noop.

если бы это зависело от планировщика, 12309 бы не было. но тут в целом кривая реализация работы с io не скажу какого компонента, т.к. не знаю наизусть все системы.

Если исходить из того, что работа идёт SSD+USB, то BFQ или иной io scheduler для HDD здесь не нужен как раз. Проблема в том, что планировщики такого рода нужны чтобы вращающиеся шпиндели и перепозиционирующиеся головки учесть и задержки, которые из-за этих процессов возникают

У меня жесткий диск. Правило udev устанавливает bfq для жестких дисков. Для остального остается дефолтный mq-deadline.

Там ботл-нек в обрабочике прырваний от HDD. Какого-то х*я в обрабочике захватывается два спин-лока, в то время как по-нормальному — ни одного.

хмм. подумалось что совпадение, раз в raid я сталкивался с этим чаще. типа проблема умножается на число дисков.

Эммм...

что за простыню я прочёл?

Вопрос «зачем Вы её прочли» задавать надо? Шучу. =)

на копирование флешки одно ядро, а для просмотре ютюба перезагружаться в другое ядро? ты угараешь?

Нет конечно же. Зачем до абсурда-то доводить? Если это «классический» десктоп, то и ядро под него «классическое» десктопное.

если бы это зависело от планировщика, 12309 бы не было. но тут в целом кривая реализация работы с io не скажу какого компонента, т.к. не знаю наизусть все системы.

Да там куча всего. Оно не зря в ядре куча параметров, которые позволяют конфигурировать его как необходимо, под текущие задачи, а не «как-то вообще». Если, например, мне зачем-то нужен router, а не host, то почему бы мне не выставить IP_ADVANCED_ROUTER=y?

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

По сути, понятие «производительность ядра» и «производительность системы» это понятия такие… «интегральные», которые зависят от ряда факторов.

Попробуйте 1000Hz?

CONFIG_HZ_300=y

1000Hz это следующий же параметр в данном разделе. Я не знаю какой у Вас проц, просто пересоберите с 1000Hz и проверьте?

Ясно.

У меня жесткий диск. Правило udev устанавливает bfq для жестких дисков. Для остального остается дефолтный mq-deadline.

Можете проверить какой подойдёт планировщик лучше. Как-то так, например, только надо будет модифицировать скрипт для того, чтобы он поддерживал bfq. Ну а дальше уже сами определитесь.

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

4.2

int main()
{
    while(1)
    {
        malloc(100);
        usleep(1);
    }
}

strace ./sbrk-test 2>&1 |grep -v clock
execve("./sbrk-test", ["./sbrk-test"], 0x7fffffffda00 /* 85 vars */) = 0
brk(NULL)                               = 0x405000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (Нет такого файла или каталога)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=129646, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 129646, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7f98000
close(3)                                = 0
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\3408\2\0\0\0\0\0"..., 832) = 832
newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=2338808, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff7f96000
mmap(NULL, 2351664, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffff7d57000
mprotect(0x7ffff7d79000, 2174976, PROT_NONE) = 0
mmap(0x7ffff7d79000, 1867776, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7ffff7d79000
mmap(0x7ffff7f41000, 303104, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ea000) = 0x7ffff7f41000
mmap(0x7ffff7f8c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x234000) = 0x7ffff7f8c000
mmap(0x7ffff7f92000, 12848, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffff7f92000
close(3)                                = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff7d55000
arch_prctl(ARCH_SET_FS, 0x7ffff7f97580) = 0
mprotect(0x7ffff7f8c000, 16384, PROT_READ) = 0
mprotect(0x403000, 4096, PROT_READ)     = 0
mprotect(0x7ffff7ffb000, 8192, PROT_READ) = 0
munmap(0x7ffff7f98000, 129646)          = 0
brk(NULL)                               = 0x405000
brk(0x426000)                           = 0x426000
brk(0x447000)                           = 0x447000
brk(0x468000)                           = 0x468000
brk(0x489000)                           = 0x489000
brk(0x4aa000)                           = 0x4aa000
brk(0x4cb000)                           = 0x4cb000
brk(0x4ec000)                           = 0x4ec000
brk(0x50d000)                           = 0x50d000
brk(0x52e000)                           = 0x52e000
brk(0x54f000)                           = 0x54f000
brk(0x570000)                           = 0x570000
brk(0x591000)                           = 0x591000
brk(0x5b2000)                           = 0x5b2000
brk(0x5d3000)                           = 0x5d3000
brk(0x5f4000)                           = 0x5f4000
brk(0x615000)                           = 0x615000
brk(0x636000)                           = 0x636000
brk(0x657000)                           = 0x657000
brk(0x678000)                           = 0x678000
brk(0x699000)                           = 0x699000
brk(0x6ba000)                           = 0x6ba000

Пушто I/O в линуксе имеет повышенный приоритет. Во FreeBSD, SunOS и т.д. такой фигни нет.

Ведь юникс изначально

… прошивка для серверов. А серверные инфраструктуры редко оперируют флешками.

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

Что ж я могу вам сказать - вы довольно нетипичный пользователь.

Не подтверждаю у себя, но подозреваю что зависит.

https://sourceware.org/glibc/wiki/MallocInternals

Я знаю что для больших аллокаций mmap, но тормозит скорее всего именно из-за малых

А тиринг это одно из проявлений 12309. Видимых.

Нет конечно. Но тут уже видать серьезное поеханье.

Такое часто бывает у гентушников. Синдром ребёнка с игрушечным рулём в автобусе. Когда он считает, что ведёт автобус.

Так и тут на основе весьма ограниченных ручек для манипуляции искажается реальная картина мира, и пациенту кажется, что он управляет вещами, хотя ручек на управления им нету (точнее есть, но не там).

Страница прогрузилась в память, нужные сейчас части интерфейса браузера тоже. Я хочу прокрутить страницу. И тут все заисает. Где тут доступ к незагруженным страницам?

Отвечу словами Берга:

«the kernel into the situation where it must remove executables/libraries from main memory. If that happens, you can end up hitting the disk for every function call.»

Иными словами, процессам нужна не тольоко анонимная память, но и доступ к кэшу библиотек, лежащих на диске, в основном в /usr.

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

Анонимная память — это непосредственно исполняемый код процесса, да? А чем он отличается от кеша библиотек?

Итак, я вернул настройки в /etc/sysctl.conf к дефолтным значениям, закинул на флешку десять гигабайт видео (специально воткнул ее в USB 2.0). Симптомов 12309 не наблюдал. Таки вылечили, или один эксперимент — не статистика?

А чем отличаются файловые страницы от анонимных? Анонимные не связаны с ФС, файловые свзяны с ФС - восстановление файловых страниц предполагает их удаление из памяти, так как их в любой момент можно считать с диска. Анонимная память - это собственно данные программ, лежат только в памяти и не имеют копии на диске. Восстановление анонимных страниц предполагает их вытеснение в своп. Кэш библиотек - это просто кэш файлов библиотек. Выполнениие процесса требует либ и чтения исполняемого кода. На одной анонимной памяти далеко не уедешь. Система без кэша - это зависшая система со светящимся индикатором жесткого диска.

А ты копируй на флэшку и потом запусти tail /dev/zero.

То есть все сводится к тому, что должна быть свободная память для мапов библиотек а кеш FS может что-то вытеснять из памяти? Это как бы похоже на баг, так как кеш FS не должен ничего вытеснять из памяти а только занимать свободную память…

Понял. То есть, исполняемый код процесса, откртые им файлы — это дисковый кеш, не связанные с файлами данные — анонимная память. При наступлении 12309 память занимается грязным кешем, анонимные страницы идут в свап, файловый кеш на диск. В результате, гуй и пользовательские процессы работают с диска.

После копирования или во время?

И смысл твоих пачтей сводится к тому, чтобы заставить систему держать файловый кеш в памяти, правильно?

во время, разумеется. Копируешь, накапливаешь гигабайт грязного кэша, запускаешь пожиратель памяти. Чистый кэш приблизится к минимуму, система зависнет - ООМ не придет, пока не запишется весь кэш на диск - а это может быть долго. У меня 8 МБ/c скорость записи на флэшку, например.

Ну да, все так. Сейчас чистый кэш беззащитен - он можент бытьвытеснен как грязным, так и анонимной памятью. Патч добавляет возможность защищать заданный объем чистого кэша.

Грязный кэш может вытеснять чистый кэш (кэш либ). Если указать в абсолютном значении dirty_bytes, то грязный кэш в этих пределах будет иметь высокий приоритет и запросто вытесняет анонимку в своп, а чистый кэш запросто может быть вытеснен грязным при копировании.

так почему бы не отключить этот грязный кеш, хотя не, пока писал,
понял что непонятно, а какого фига страницы кеша одних приложений зависят от других и не могут оперироваться независимо? что за пузырьковый bdsm в 2021 году?