Вышло ядро Linux 2.6.39

Знакомься:

Я кадата уже читал. Там в кучу намешано всё, что хоть как-то имеет отношение к высокой латенси, каждый пользователь может найти «это моё, чините!» и ни один разработчик не может в итоге чётко понять куда же смотреть.

Да, есть мнение, что этот патч упешно маскирует проблему.

Есть подозрение, что постоянное совершенствование BIO проблему часто не просто маскирует, а решает.

> на винт при этом постоянно пишется со скоростью примерно 70мб/сек

Если ФС поддерживает posix_fallocate (ext4, btrfs, xfs afaik), то поищи в торрент-клиенте настройку выделения места под её тип. Выполняться будет мгновенно.

> есть мнение, что этот патч упешно маскирует проблему.

В данном случае проблемы не видно == проблемы нет, не? Или за счет чего по-твоему её замаскировали?

> А у многих при этом еще мышь еле двигается и всё тормозит.

Так пусть эти «многие» наконец выложат содержимое /proc/interrupts до и после воспроизведенияс проблемы, а также вывод `vmstat 1` во время. А то одни слухи о том, что кто-то слышал о том, что кто-то видел того, у кого это воспроизводится. И ни одного, кто реально это воспроизвел и выложил логи.

> ЕМНИП сам баг (именно который 12309) уже давненько точно определен (т.е. известно, что к нему приводит и в чем неправильное поведение)

Линк?

точно был на лоре линк на одного из разработчиков ядра, который это утверждал. Месяца 2 назад тут обуждали уже(как новое ядро выходит, кто-то всегда требует этот линк), но я его не сохранил -.- Смотри в теме о .38 версии.

У меня было 12309 на других ядрах, сейчас нету вообще, а так бы выложил.

>> есть мнение, что этот патч упешно маскирует проблему.

В данном случае проблемы не видно == проблемы нет, не?

Не.

за счет чего по-твоему её замаскировали?

Проблема в том (ИМХО), что ядро хреново управляет ресурсами на глобальном уровне. Поэтому через контейнерную подистему ему подсказали «ограничивай потребление вот этой группы процессов».

Замечательный релиз. Собираем-с (правда я предпочитаю 100% безблобовую -libre ветку: http://www.fsfla.org/svnwiki/selibre/linux-libre/download/releases/LATEST-2.6...).

Рилтаймофилы и многопроцессорщки в восторге, понимаю (хоть и пользуюсь CONFIG_PREEMPT_NONE=y, да и процессор у меня один и одноглазый). Btrfs планирую таки наконец попробовать.

А вот на это они бы лучше время вообще не тратили: :-)

внесены изменения в планировщик процессов, исправляющие проблемы с виртуализацией Windows;
добавлен драйвер мыши для Hyper-V;

> Проблема в том (ИМХО), что ядро хреново управляет ресурсами на глобальном уровне. Поэтому через контейнерную подистему ему подсказали «ограничивай потребление вот этой группы процессов».

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

> Тогда должна упасть производительность дисковых операций, так?

Не обязательно. Если это проблема в VM (а выглядит именно так), то производительность дискового В/В может даже возрасти.

Хех, первый билд не удался. Почти в самом начале. И чо они так любят -Werror и не проверяют сборку с GCC 4.6?

arch/powerpc/kernel/crash.c: In function'default_machine_crash_shutdown':
arch/powerpc/kernel/crash.c:349:2: error: implicit declaration of function 'crash_kexec_wait_realmode' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
fs/ecryptfs/file.c: In function 'ecryptfs_open':
fs/ecryptfs/file.c:161:17: warning: variable 'lower_dentry' set but not used [-Wunused-but-set-variable]
make[1]: *** [arch/powerpc/kernel/crash.o] Error 1
make: *** [arch/powerpc/kernel] Error 2

> проблема в VM

virtual memory?

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

Блин, и ведь CONFIG_PPC_DISABLE_WERROR=y то включён у меня... Ну что ж они так? Бетмены, блин, влепили -Werror-implicit-function-declaration, а прототип пожалели объявить.

>> проблема в VM

virtual memory?

Да.

Какой группе процессов (юзерспейса или ядра?) можно ограничить потребление процессорного времени

Эээ... думаю, это точно не ядерные процессы :) Деталей фунционирования autogroup не знаю.

> думаю, это точно не ядерные процессы :)

Ок. Если понизить юзерспейсной софтине приоритет, ядро станет получать от неё read и write с меньшей частотой; другими словами, какая-нибудь cp будет читать и писать дольше. Не так?

А хотя нет, это наверное относилось бы только к синхронному io.

Так, ладно. Собралось. Работает офигенчик (по крайней мере не хуже 2.6.38.6). Пришлось, правда, KEXEC в конфиге отключить, чтобы собралось.

$ uname -a
Linux localhost 2.6.39-libre-powerpc #1 SMP Sun May 22 01:00:42 UTC 2011 ppc ppc ppc GNU/Linux
$ uptime
 10:31:19 up 12 min,  5 users,  load average: 5.25, 3.65, 2.83
$ ls -l /boot/vmlinux-2.6.39-libre-powerpc
-rwxr-xr-x 1 root root 9890573 2011-05-22 06:35 /boot/vmlinux-2.6.39-libre-powerpc

> Если понизить юзерспейсной софтине приоритет, ядро станет получать от неё read и write с меньшей частотой; другими словами, какая-нибудь cp будет читать и писать дольше. Не так?

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

> Пришлось, правда, KEXEC в конфиге отключить, чтобы собралось.

А что с ним было не так? Я с KEXEC собрал, правда резервное ядро всё равно даже не загрузилось.

главное, что в новые ядра пихают поддержку нового оборудования, вот бы еще CFS на BFS сменили, было бы неплохо, ждемс, Линус вперед!

Ну я же сверху писал, почему. Они не объявили прототип, просто добавили функцию. Ерроры см. выше. Почему не отписал в LKML, а тупо отрубил KEXEC? Потому что уже куча репортов было, они гуглабельны. Просто это не хрен86, если ты понимаешь о чём я.

> Железо - проверенное-перепроверенное. Один из «железа» крутится 24х7 как торрент-раздатка.

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

запускал хроминиум (далее, хром) - на определённом сайте «вышибало» в ребут.

На Бубунту ЛТС с 32-м ядром тоже «выскакивал» хром + вис 4.0.1 ФФ (с системой вместе) на ряде сайтов, ixbt, по моему.

Может быть виноват и иксовый драйвер. Если он при управлении картой запишет что-то не туда (а у тебя видео встроенное, правильно?), то железо вполне может сброситься/зависнуть. Чтобы исключить иксовый драйвер, можно попробовать другой драйвер (vesa, например).

ТС, блин, где pf-39?
ждёшь TuxOnIce?

Да. Невтерпёж — ставь из гита то, что есть.

Может быть виноват и иксовый драйвер.

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

Если он при управлении картой запишет что-то не туда (а у тебя видео встроенное, правильно?), то железо вполне может сброситься/зависнуть.

Нет, железо то - разное, т.е. два разных компа. Причём очень разное: P3 800 и ноут на Core 2 Duo. И на последнем NV8600MGT. Так что не в драйверах дело, скорее всего.

Не показатель. Твоя торрент-раздатка может не использовать глючный девайс вообще.

Не может. Часто с торрентом крутится и deadbeef. А кроме доп. звуковухи ничего лишнего нет.

ну что же надо обновиться

>>Может быть виноват и иксовый драйвер.

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

Иксы пишут прямо в железо, минуя ядро. Глючный драйвер может ресетнуть или завесить чипсет.

Если он при управлении картой запишет что-то не туда (а у тебя видео встроенное, правильно?), то железо вполне может сброситься/зависнуть.

Нет, железо то - разное, т.е. два разных компа. Причём очень разное: P3 800 и ноут на Core 2 Duo. И на последнем NV8600MGT. Так что не в драйверах дело, скорее всего.

У меня P3-1000,(туалатин, разогнанный до 1300, чтоли) имел аптайм больше года. Всё время крутился торрент, осёл, vdr (кабельное на винт записывал), Х'ы и, или mplayer, или браузер или вместе. Предыдущая машинка, да, вешалась и виной был закрытый драйвер fcdsl, вешающий PCI при большом количестве соеднинеий. Выкинул его и завиасаний больше не было.

Сейчас Core 2 Duo - работает круглые сутки - всё тоже самое, кроме ненужного больше осла, (но зато либо виртуалка qemu включена, либо qemu компилится, LA редко падает меньше полутора) и за 3 года тоже ни одного зависания.

Так что, проблемы наверняка с железом, и в первую очередь надо избавляться от закрытых дров (кроме Нвидиа, они вроде бы, с 2002года надёжные стали).

На счет эму:

Работает везде (и в броузерах)?

Как настраивали можно узнать?

Я использовал утилитку asoundconf, она нагородила тучу всего в ~/.asound.config, я так и не понял как оно работает, все нет времени разобраться.

> Иксы пишут прямо в железо, минуя ядро.

Что, в ring3 уже можно писать в порты?

Уел, вылезаю из криокамеры. Теперь это делается через drm, но это мало что поменяло.

Уже собрали kernel 2.6.39 rpm в Fedora, openSUSE.

оно уже почти везде есть