Баг 12309

В тред приглашаются телепаты.

Ну а че, просто пусть люди выскажут что слышали. Как прогресс на этом фронте? Как залатать костылем?

не встречал

Так бы и написал: «Мне лень гуглить и читать багтрекер, так что расскажите, кто что знает.»

www.linux.org.ru/wiki/en/User:shimon/12309 —читал?

Поставь High IO priority, а вот юзерспейсу приоритет понизь.

мне помогло

vm.dirty_background_bytes = 2097152
vm.dirty_bytes = 2097152

Как прогресс на этом фронте? Как залатать костылем?

У половины это не проявляеться, другой половине потребовался pf-sources, у третьей половины - карма ...

Техническая причина в интеграции контроллёра памяти в ядро процессора.

Хм, а как же в других ОС?

а как же в других ОС?

В других ОС хорошая программная архитектура, которой этот технический аспект по барабану.

У меня последнее время на амд-десктопе и интел-ноутбуке очень жестко временами подвисает все. Наверное, 12309?

Покупка 4Гб памяти немного улучшила ситуацию.

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

Моя идея не является инструкцией как всё сделать хорошо, а лишь «как надо было правильно делать ядро». Суть её такова: чем меньше байт записывается за операцию, тем выше у неё должен быть приоритет. То есть, если мы копируем 100ГБ файл, то у него IO-приоритет должен быть близкий к idle. Стоит какой-нибудь программе записать 10 байт, как этой операции установится максимальный приоритет и она выполнится тут же, приостановив запись 100 ГБ.

Обоснование:

1) Если файл копируется 1 час, то ничего плохого, что он скопируется на несколько минут дольше.

2) Если файл копируется 1 секунду, то даже промедление на несколько секунд будет заметно.

Поэтому любые мелкие дисковые операции должны вытеснять более продолжительные.

Где я не прав и почему так не сделали в ядре?

Это называется earliest deadline first scheduling. BFS реализует разновидность этого алгоритма для планирования задач, что даёт существенный прирост отзывчивости, по сравнению с CFS. Думаю, ты прав, планировщик ввода-вывода с таким алгоритмом улучшил бы ситуацию.

Где я не прав

man Кэширование. Если ради каждых 10 байт винт на seek и write дергать, то 12309 раем покажется.

Ты видимо имел ввиду переупорядочивание дисковых операций. Одно другому не противоречит.

Нет, именно кэширование записи. А переупорядочиванием сейчас вообще NCQ занимается. И это еще как противоречит.

Если для каждой операции известен deadline, мы можем планировать ввод-вывод с учетом переупорядочивания операций, пока вписываемся в deadline-ы. Думай.

Я не имел ввиду sync. Я имел ввиду, что есть очередь запросов на запись. Обычно операции добавляются в конец очереди и выполняются по порядку. Но если мы хотим записать 10 байт, то это эта операция добавляется в самое начало очереди, нарушая порядок.

Если для каждой операции известен deadline

Ключевое слово «известен». А когда он бывает известен на уровне ядра? Ну записал я BMPHeader и подготавливаю картинку туманности M31 в разрешении дофига*дофига, откуда ядру знать, что за записью десятков байт через пару секунд пойдет запись десятков мегабайт в этот же файл?

Посмотри, как BFS устроен. Мы можем назначать операциям виртуальные deadline-ы на основании поведения программы. Плюс к этому, на deadline влияет значение nice.

Пока запись идет в кэш, порядок не имеет особого значения.

Это все гадание на кофейной гуще. По крайней мере, те несколько раз, что я пытался решить проблему с 12309 самосбором ядра с bfs ни разу проблемы не решили. А вот новое ядро с дефолтным cfs - вполне себе решили.

Не верил всем, что есть 12309 . Но однажды столкнулся, потом поставил другое ядро и снова: «А разве 12309 существует?»

Я говорил про очередь сброса кеша на диск.

BFS никакого отношения к проблеме 12309 не имеет.

Причина в современном железе у разработчиков ядра.
У меня на одной машинке с 8Gb RAM 12309 тоже не проявляется.
Посадить бы их всех на какие-нибудь P4/1Gb - быстро бы починили... :)

i3 330m и 4гб памяти - не современное железо?

4Gb не спасают?
У меня: P4-3Ghz/2Gb - 12309 есть, i5-2500/8Gb - 12309 нету.

не спасают

Прописал в sysctl.conf:

vm.overcommit_memory = 2
vm.dirty_background_bytes = 2097152
vm.dirty_bytes = 2097152

$ cat /proc/sys/vm/{overcommit_memory,dirty_bytes,dirty_background_bytes}
2
0
0

$ eselect rc list | grep sysctl
  sysctl                    boot

Техническая причина в интеграции контроллёра памяти в ядро процессора.

Интересно, отчего же это он тогда на Core 2 проявлялся вовсю?

Техническая причина в интеграции контроллёра памяти в ядро процессора.

феерический бред

Что-то трогает эти параметры уже после sysctl?

Вероятно. Что-то дистроспецифичное.

Gentoo, +1

12309 пропадает где-то в районе 6 ГБ. У меня на 4 ГБ ещё есть, а вот у знакомого на 6 ГБ уже всё нормально.

Есть разные машинки - 512Mb, 1Gb, 2Gb, везде 12309 нету. Как включить?

Я подозреваю, что дело - только в чипсете.

Есть разные машинки - 512Mb, 1Gb, 2Gb, везде 12309 нету. Как включить?

Напиши в багтрекер, что у тебя не включается.

Я тоже хочу увидеть, и у меня тоже без него - наверное, Linux бракованный.

.

А вообще, это больше элемент пропаганды.

А вообще, это больше элемент пропаганды.

Отнюдь нет. Я вообще сторонник Linux и сую его куда надо и не надо, так что очернять его специально не буду. Однако признаю, что на моём декстопе 12309 ЕСТЬ. Чтобы его увидеть надо скопировать файл в несколько ГБ.

В то же время у двух знакомых (у одного 6 ГБ оперативки, у другого ноут с SSD) 12309 НЕТ.

Захешировать 10Гб по^W мультиков про Винни-Пуха rtorrent-ом.
Законпелять chromium/virtualbox.
На моей P4/2Gb это гарантированно вызывает 12309.

Захешировать 10Гб по^W мультиков про Винни-Пуха rtorrent-ом.

Хоть сто. Отзывчивость не теряется.

Законпелять chromium/virtualbox

С make -j1 даже не замечу. С рекомендованным make -j3 (число_ядер+1) определенная неспешность появляется, но 100% загрузка процессора к 12309 отношения не имеет.

С рекомендованным make -j3 (число_ядер+1) определенная неспешность появляется

Это лечится при помощи BFS и verynice.

Хоть сто. Отзывчивость не теряется.

Реквестирую рецепт.

С make -j1 даже не замечу.

У меня тоже MAKEOPTS="-j1".
В процессе сборки virtualbox в какой-то момент времени cc и as в сумме начинают отхавывать ~1.8Gb памяти. В этот момент даже в консольке не залогиниться - вылетает по таймауту.

В процессе сборки virtualbox в какой-то момент времени cc и as в сумме начинают отхавывать ~1.8Gb памяти. В этот момент даже в консольке не залогиниться - вылетает по таймауту.

ОЗУ сколько в системе? Своп есть?

Это лечится при помощи BFS и verynice.

Найс не помогает:
PORTAGE_NICENESS=15
PORTAGE_IONICE_COMMAND=«ionice -c 3 -p \${PID}»

А от BFS вроде бы нет толку на одноядерных CPU.

ОЗУ сколько в системе? Своп есть?

2Gb RAM + 2Gb swap

Найс не помогает:

И не поможет на CFS. CFS игнорирует приоритеты.

А от BFS вроде бы нет толку на одноядерных CPU.

А разработчик BFS об этой шокирующей новости знает?

Тормоза при своппинге — это отдельная песня. Если на файловом IO лагов нет, это не 12309.

А разработчик BFS об этой шокирующей новости знает?

Наверное знает, одноядерные железки практически вымерли уже.

Если на файловом IO лагов нет, это не 12309.

%wa over 90, видимо есть.