Очередной 12309-капец. Теперь и без патча и на любых вёдрах.

io sched, CPU sched, VM?

тоже нет
каким оно боком?
а вообще про i/o - нам доступно только выбрать планировщика очереди, но никак не планирование приоритетов и т.д. (я про планировщики ввода-вывода) а ведь запросы то поступают не напрямую к планировщикам...

>к планировщикам ввода-вывода 12309 не имеет никакого отношения
Как не имеет то? Большой I/O рождает фризы

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

Убедил :)

>Большой I/O рождает фризы

Дело в том, что не сам io, а именно iowait от того, что один процесс блокирует весь доступ к харду.

Такой вопрос - а хоть где-нибудь есть схема того, как идут io запросы от приложений через ядро к харду?

Может есть какой-нибудь тест, показывающий есть 12309 или нету, чтоб определить в какой версии ядра и каким патчем поломали?

Может есть какой-нибудь тест, показывающий есть 12309 или нету, чтоб определить в какой версии ядра и каким патчем поломали?

В багзиле ядра всё это было. Сломали вроде как после 18-го.

хмм... Еще более странные результаты..

.37 без BKL. В CFQ заданы очень низкие таймслайсы (25) для всего.
dd убивается с задержкой в 7-10 секунд, но другие приложения практически не виснут.

> iowait от того, что один процесс блокирует весь доступ к харду.
нет
не только к винте, но вообще весь ввод вывод блокируется - та же мыша-клава-и_т.д.

Оно с BFS несовместимо :-/

Ну да попробуем...

>не только к винте, но вообще весь ввод вывод блокируется - та же мыша-клава-и_т.д.

Интересно, как такой ход в голову мог придти разработчикам?

После появления того патча что-то тут стало уныло. Видимо все заняты компилянием и тестами патча.

После появления того патча что-то тут стало уныло.

Патч появился на три аналогичных темы раньше. Это последний топик на эту тему.

неа - тот патчик конечно хорош, но интерактив с бфс круче
а 12309 у меня можно получить только при жутком своппинге и то
надо постараться - если тока dd
а вообще
for i in `pidof kswapd0`; do renice -n 19 $i; done
renice -n -18 -u user
и

#!/bin/bash
while [ 'pidof X' != '0' ]
do
sleep 2 && renice -18 $(pidof X) >/dev/null
done
рулят аж нимогу

и да - по поводу i/o приоритета
/*
* if process has set io priority explicitly, use that. if not, convert
* the cpu scheduler nice value to an io priority
*/

да оно и вот так неплохо

 desktop megabaks # cat scripts/renice/renice 
#!/bin/bash
while [ 'pidof X' != '0' ]
do
sleep 2 && renice -n -18 -u megabaks &>/dev/null
sleep 2 && renice -n -18 `pidof X` &>/dev/null
sleep 2 &&ionice -n 0 -t -c 1 -p `pgrep -u megabaks` 0 &>/dev/null
done

for i in `pidof kswapd0`; do renice -n 19 $i; done
desktop megabaks # 

не - ещё лучше вариант - в продолжение
without autogroup

desktop megabaks # dd if=/dev/zero of=/var/tmp/portage/test bs=200MB 
dd: запись «/var/tmp/portage/test»: На устройстве кончилось место
12+0 записей считано
11+0 записей написано
 скопировано 2304606208 байт (2,3 GB), 41,8703 c, 55,0 MB/c
desktop megabaks #

desktop megabaks # dd if=/dev/zero of=/var/tmp/portage/test bs=200MB 
dd: запись «/var/tmp/portage/test»: На устройстве кончилось место
12+0 записей считано
11+0 записей написано
 скопировано 2304606208 байт (2,3 GB), 16,3702 c, 141 MB/c
desktop megabaks # 

desktop megabaks # cat scripts/renice/renice
#!/bin/bash
while [ 'pidof X' != '0' ]
do
sleep 2 && renice -n -19 -u megabaks &>/dev/null
sleep 2 && renice -n -19 `pidof X` &>/dev/null
sleep 2 &&ionice -n 0 -t -c 1 -p `pgrep -u megabaks` 0 &>/dev/null
sleep 2 &&ionice -n 7 -t -c 3 -p `pgrep -u root` && ionice -n 0 -t -c 1 -p `pidof X`  0 &>/dev/null
done

for i in `pidof kswapd0`; do renice -n 19 $i; done
desktop megabaks # 

desktop megabaks # dd if=/dev/zero of=/var/tmp/portage/test bs=200MB 
dd: запись «/var/tmp/portage/test»: На устройстве кончилось место
12+0 записей считано
11+0 записей написано
 скопировано 2304606208 байт (2,3 GB), 16,1933 c, 142 MB/c
desktop megabaks #

Ну вот как сутки уже использую это решение ( Debian testing amd64, 32 ведро из дистра)

Да, система значительно отзывчива и не вязнет при 100% загрузке 3-x ядерного CPU у меня. Как-то лучше и с HDD нагрузками стало.
Возможно, что это не последние места для оптимизаций.

Почитал обсуждение этого способа http://lkml.org/lkml/2010/11/16/392
Печально, что понятухи и прогнозирования от своих действий у ядроклепателей уже нет... это уже «Вавилонская башня» ))

это давно эта самая башня
иначе бы уже на 18-ом ядре говном накормили бы девелоперов