Почему при высокой дисковой нагрузке (и 12309) случаются зависания?

Потому что это линукс, в котором происходит обслуживание корпораций а не обычных людей
Всем срать на то что от этого происходят адские тормоза, и даже если кто-то выпустит патч, который вернет io подсистему линукса до состояния <2.6.12, то потом какими-то левыми изменениями от «известных контор» все это пойдет прахом, и Линус-пальцепоказыватель этого даже не заметит

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

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

Может <2.6.23?

Хм. Я листаю википедию. Страница прогрузилась в память, нужные сейчас части интерфейса браузера тоже. Я хочу прокрутить страницу. И тут все заисает. Где тут доступ к незагруженным страницам? Далее, при 12309 зависает даже курсор (или начинает двигатся рывками) — курсору тоже позарез нужен диск? Я специально оговорил, что рассматриваются задачи, которым на момент зависания диск не нужен. Более того, в случае с 12309 данные пишутся на флешку. Как это мешает считать несколько килобайт с системного диска?

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

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

А ядро ждет, пока кеш сбросится на тормозную флешку и не дает никому процессор.

Это, конечно, чушь.

Почему тогда зависают процессы, которым не нужен диск?

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

Диск нужен практически всем процессам. Чтобы процессор выполнял команды, ему нужно их считывать из памяти. В памяти они появляются от маппинга файла на диске в память. И легко выбрасываются, если ядро считает, что ему нужно больше памяти.

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

Скорей всего ты ошибаешься и на самом деле памяти таки не достаточно

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

Но пока у меня заполнен кеш записи, можно считать нужные данные с диска? Почему нет?

На самом деле он не ошибается, и памяти может быть и 32ГБ и будет такая ситуация что будет или тупить-тормозить, или у тебя файл «запишется» на флешку, а потом тебе надо будет 5 минут ждать сейфремува.
2021, для десктопа готов.

Буду эксперементировать. Спасибо за ответ.

Кстати, можно ли сбросить значения параметров ядра, удалив /etc/sysctl.conf?

Так вот, почему стопорятся задачи, никак не связанные с записью на флешку (это даже не системный диск!)?

сейчас к тебе в тему прибегут наркоманы двух типов:
первые начнут утверждать, что у тебя обязательно закончилось ОЗУ
вторые будут кричать, что ты изнасиловал дистрибутив линукс, вломал ядро и крякнул планировщик i/o, а бедный рафик неуиноват, всё работало идеально.

Вроде, уже договорились, что 12309 инвариантен относительно планировщика. Этот вывод ты привел в одной из своих тем про тормоза.

вот мой конфиг с подорожником:

/etc/sysctl.conf
включённый zswap:
zswap.enabled=1 zswap.max_pool_percent=90
+свопфайл 4 гб на быстром сата ссд


/etc/sysctl.conf
vm.swappiness=60
vm.vfs_cache_pressure=50
vm.dirty_writeback_centisecs=15000
vm.overcommit_ratio = 100
vm.overcommit_memory = 1

что у тебя обязательно закончилось ОЗУ

Буду пытать пациента. Нужно экспериментировать. Пока да, это объяснение мне не очень нравится. Но нужно проверить.

так значит это alsa виновата![/сарказм]

Ведь юникс изначально многозадачная система,

Да, сынок, сейчас только файл на флешку допишу.

vm.vfs_cache_pressure=50

Мне говорили, что так делать не нужно. Много памяти просирается на кеш файловой системы.

В смысле, пытать линукс, а не легионера :)

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

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

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

Тоесть если подкачку выключить, то зависаний не будет?

Но пока у меня заполнен кеш записи, можно считать нужные данные с диска?

Там разве не единый кеш?

Перекидываем что-нибудь жирное с ssd на допотопную USB 2.0 флешку.

Делаю именно это. Система не то что не зависает, а вообще никак процесс копирования ни на что не влияет. ЧЯДНТ?

ЧЯДНТ?

А тюнингом, вообще, занимаешься?

Всё так делаешь. Там от многих факторов зависит. В том числе от версии ядра.

Налететь довольно легко. Но это не значит, что гарантированно.

Это козни microsoft. А 12309 во-первых никогда не существовало, а во-вторых его давно починили.

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

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

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

На FreeBSD такой проблемы, что ты описал в шапке темы, не наблюдается.

Вот если ты и этот механизм каким-то образом изменишь (что достаточно сложно)

Указать что надо весь файл в память загрузить. В флагах mmap наверное что-то такое есть.

т.к это маппинг, страницы освободятся как только кому-то потребуется sbrk()

На FreeBSD такой проблемы, что ты описал в шапке темы, не наблюдается.

Это неправда. На моём старом ПК, где подобная проблема проявлялась, в FreeBSD всё было один в один.

Конфиг в студию.

Конфиг чего?

Если речь об аппаратном обеспечении, то: AMD Athlon XP 2500+, Epox 8RDA3+, 3 ГБ ОЗУ.

Проявлялось при копировании на медленные внешние носители вроде USB-флешек. Внешние признаки: прерывистое движение курсора, замирания картинки на секунду-полторы, высокий iowait.

FreeBSD 9, Xfce.

У себя на AthlonXP 2500+ и Athlon X2 3800+ не припомню такого.

Очевидно, что дело не только и не столько в процессоре.

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

Требуется рефакторинг block-device framework

А сколько памяти? Так то 12309 можно просто закинуть большим объемом памяти и не замечать проблем. Я уменьшил размер грязного кеша и тоже не земечаю, но мне интересно, откуда эта байда берется.

У меня Android виснет если на sdcard переместить активно дергающие в фоне файлы недоаппсы

Может это драйверы плохо написаны или контроллер io разгрузку не может?

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

А сколько памяти? Так то 12309 можно просто закинуть большим объемом памяти и не замечать проблем

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

Может это драйверы плохо написаны или контроллер io разгрузку не может?

Один из носителей явно работает в режиме PIO, а не DMA.

Я на днях забивал нулами внешний винт, и ничего, казалось бы, не тормозило. Но в это же время я попытался отформатировать один из разделов SSD, операция в Gnome Disks зависла, Gparted вообще сначала подвис, а потом ни в какую не убивался по kill -9, пока диск не забился до конца. Как думаешь, это оно же, или что-то другое?