[12309?]фризы при копировании на винтах

iowait?

Я предлагаю банить каждого, кто говорит про 12309, и при этом не упоминает, пробовал ли он совет по ссылке www.linux.org.ru/wiki/en/User:shimon/12309 и насколько он помог.

Потому что это вторая (после ссылки на лурку) ссылка в гугле по запросу 12309, черт побери.

И я совершенно серьёзно.

пардон, забыл добавить - перечисленые методы не помогли, взамен поймал многочисленые глюки с отваливанием kwin, непонятные ошибки при компиляции и прочая прочая (как я понял, проявляется тогда, когда память забивается хотя бы на 50%). ОЗУ 4 гига.

Тогда верни на место настройки, касающиеся оверкоммита, и попробуй настройки dirty_bytes. Пробовал их?

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

Кусок закоментеного sysctl.conf:

#vm.overcommit_memory = 2
#vm.overcommit_ratio = 80
#vm.dirty_background_bytes = 4194304
#vm.dirty_bytes = 4194304

глюки с отваливанием kwin, непонятные ошибки при компиляции и прочая прочая

dirty_bytes

Это крайне странно.

я вечером ковырну, отпишу сюда:)

Своп нужен. man proc за подробностями.

Своп есть, 2 гига.

Возможно, надо больше. В общем, смотри формулу в мане и считай, сколько с твоими потребностями нужно.

Сейчас у меня 8 Гб памяти и 4 Гб свопа, пока проблем не было, но ничего сверхжирного не запускается. Настройки такие:

vm.overcommit_memory = 2
vm.overcommit_ratio = 60

dirty:

vm.dirty_background_bytes = 4194304
vm.dirty_bytes = 4194304

12309 и так не было, но идея настройки показалась здравой.

взамен поймал многочисленые глюки с отваливанием kwin, непонятные ошибки при компиляции и прочая прочая

неудивительно, overcommit_memory=2, overcommit_ratio=80 это жесточайшая настройка, а тому кто советует её в качестве борьбы с 12309 надо отрывать яйца по самые гланды.

8 Гб памяти и 4 Гб свопа vm.overcommit_memory = 2 vm.overcommit_ratio = 60

3.1415здец

А сколько будет лучше? Последний раз я эту настройку менял при 6+6 Гб. Какие могут быть проблемы?

Мне помогли следующие шаги:

1. Установить доступ к винтам в режим ACHI

2. установить ядро liquorix

А сколько будет лучше?

90% если памяти > 8гигов. Если памяти меньше, то вообще не включать.

Какие могут быть проблемы?

«многочисленые глюки с отваливанием kwin, непонятные ошибки при компиляции и прочая прочая»

90% если памяти > 8гигов. Если памяти меньше, то вообще не включать.

А если ровно? В принципе, 12309 у меня нету, настройки крутил для интереса и устранения странных пауз при еженедельном rsync'е приличного количества хлама, когда диски не шуршат, загрузка системы околонулевая, а процесс rsync о чём-то задумывался.

Проблемы с падениями всего подряд были, когда я сдуру влепил 80% при 4 Гб без свопа.

Как сконфигурировано ядро?
zcat /proc/config.gz | grep CONFIG_IO_DELAY
Собственно, дома тоже 12309 не проявляется.

persephone:~> grep CONFIG_IO_DELAY /boot/config-$(uname -r)
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set

А что это? Вроде раньше не слышал. Ведро дистрибутивное.

У меня самосбор
zcat /proc/config.gz | grep CONFIG_IO_DELAY
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
CONFIG_IO_DELAY_NONE=y

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

CONFIG_IO_DELAY_NONE:
No port-IO delay. Will break on old boxes that require port-IO delay for certain operations. Should work on most new machines.
Symbol: IO_DELAY_NONE [=y] Type : boolean Prompt: no port-IO delay Defined at arch/x86/Kconfig.debug:217 Depends on: <choice> Location: -> Kernel hacking -> IO delay type (<choice> [=y])

Собственно, когда 12309 был на пике популярности, где-то в рассылке подсмотрел совет сменить CONFIG_IO_DELAY на NONE. Ничего плохого не произошло. Хорошего вроде бы на глаз тоже не заметил, но, почему-то отложилось в связи с этим багом.

1. ACHI стоит в биосе, в ядре поддержка есть:

00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode]

2.

# eix liquorix
No matches found.

# uname -r
3.1.10-gentoo-r1-amd64-r1

на 3.2.1-r2 аналогичная ситуация.

# zcat /proc/config.gz | grep CONFIG_IO_DELAY
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
CONFIG_IO_DELAY_NONE=y

собственно тоже что и у GotF

а, пардон, у imul такой же конфиг. Про IO delay type тоже читал, да собственно этот параметр часто попадается в манах, как избавится от 12309.

Раскоментил свои dirty bytes, полет нормальный, видимо спутал с vm.overcommit_memory и vm.overcommit_ratio (просто помню, что игрался с какими-то параметрами). Запустил копирование двух блуреек - работет получше, но видно небольшие провисания (опера 20-30 вкладок, ЛО с пустым документом, аудациоус, копыто).

Еще предложения для сведения 12309 к минимуму/исчезновению?

Еще предложения для сведения 12309 к минимуму/исчезновению?

BFQ?

юзал pf-kernel`ы, были полные зависания практически на ровном месте, лечил SysRq + reisub (хотя может дело не совсем в нем) И да, возможно ли юзать (точнее будет ли толк) BFQ без BFS (BFS заменяет cgroup)

И да, возможно ли юзать (точнее будет ли толк)

Разумеется. Они ведь никак не связаны.

Хорошо. Соберу, отпишусь.

В генте Liquorix придется конпелять из исходников

Собрал. Отгреб какую-то хрень с невозможностью подгрузить нужный модуль для sensors. вернулся на gentoo-sources, щас ковыряюсь.

Еще, кхм... Всё время забываю признаться. Я в отношении 12309, применительно к винтам, слегка читерствую. У меня Promise FastTrack TX4650 PCI-E 1X. Как бы железка за $180 себя показывает немного лучше, чем бортовый чайначип за червончик. Вот такой я нехороший человек.

попробуй еще вот что:

# echo madvise > /sys/kernel/mm/transparent_hugepage/defrag

Этот параметр в конфигулярке ядра задается, что он дает? стоит [always]

выполняется от рута, действует до перезагрузки отключает дефрагментацию страниц памяти, что не даёт приложениям входить в D-state, тем самым может улучшить отзывчивость приложений при копировании. Может сломать гибернацию.

В ядре версии 3.3 будет очередная попытка побороть баг.

https://lwn.net/Articles/475405/

если есть желание узнать о проблеме больше - читай на антимонгольком тут: http://lwn.net/Articles/467328/