Вынос обработки прерываний в отдельные потоки может решить эту проблему.

Сомневаюсь...

> Ранее ipset не было?

Только отдельным модулем, который часто не собирался на новых ядрах.
Теперь же оно в ядре, слава ийцам!

Релиз вообще весьма радующий.

Кто такие торболлы? Для них нужен TOR?

Это ты где такое увидел?

Почти как с 12309, никто не может его тольком воспроизвести,

Может. Баг чипсето-зависимый (ИМХО), мобильный Core 2 Duo на ICH9 - видно на глаз.

2.6.32 ведро.

12309 очень хорошо воспроизводится при дефиците оператианой памяти в системе.

И без дефицита тоже.

Вместо обсасывания 12309 в милионный раз, соберите это ядро и протестируйте.

>Вынос обработки прерываний в отдельные потоки может решить эту проблему.

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

Наврал (не Нать-те). ICH8 на PM965.

Попробуй

> btrfs_fsck уже работает и не портит файлы?

Попробуй и отпиши здесь. Вместо шапкозакидательства...

В продакшене, за который отвечает несколько админов? Ну уж нет. Только если это действительно понадобится из соображений безопасности, а «just for fun» здесь неприменим.

Честно говоря, не хочется. С 35-го пошёл «жор» процессора -> повысились t-ры.

Опробовано также на 36-м, 37-м.

Врёшь.

The «Forced Threaded Interrupt Handlers» shift the processing of almost all interrupts into kernel threads if the kernel is launched with the parameter «threadirqs». This process means that the .39 series now has one of the last major functions in the main development branch of Linux that the real-tme branch uses to give Linux real-time capabilities; there, the technology is, however, used by default to avoid the long latencies in the processing of interrupts.

Какой дистрибутив используете в продакшне?

Не вижу корректора.

удаление бкл надо отметить

Или с глазами что-то.

Эмм. А что тогда это в первых строчках?

That's mostly a debug option to allow retrieving better debug data from crashing interrupt handlers. If «threadirqs» is not enabled on the kernel command line, then there is no impact in the interrupt hotpath.

> произведено множество улучшений

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

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

Заметил что когда у меня плохое настроение, а новость о файловых системах, ядре или GRUB, то я открываю весь тред на одну страницу, нажимаю Ctrl-F и пишу «iZEN». И сразу становится лучше. Спасибо!

В первых строчках разработчики радуются. А теперь прикинь, как это должно влиять на отзывчивость.

Придется опять пачить vmnet (vmplayer) - оно жить не может без BKL 8). Ну да думаю что vmware в след. версии подсуетится.

>А теперь прикинь, как это должно влиять на отзывчивость.

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

А чё это за BKL, блокировка какая-то, для чего нужна была, и почему так радуюцо её удалению? :)

Эти гады нуво(3D) поломали. На машине c GeForce 250 GTS я умею вешать систему(достаточно выйти из полноэкранного режима в Dragon Player при включенных эффектах), а на машине c GeForce 8200 умею валить ядро - достаточно запустить gnome-shell. Баги на 3D уже принимают?

Выше по треду писали. Читай.

Было, но не всё. Нужно тестировать.

На машине c GeForce 250 GTS я умею вешать систему ...

а на машине c GeForce 8200 умею валить ядро...

А что-нибудь полезное вы умеете делать?

>>12309 никак не связан с BKL.

Вынос обработки прерываний в отдельные потоки может решить эту проблему.

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

Надеюсь, что так и будет :)

Это с каких пор многопоточность повышает производительность, а не отзывчивость?

Тебе сюда

>Это с каких пор многопоточность повышает производительность, а не отзывчивость?

На многоядерных процах многопоточность повышает и то, и другое

> окончательно и безвозвратно удалён BKL. Соответствующего кода в ядре больше нет. Вообще нет. Весь процесс занял около трёх лет;

Только сейчас?

> Вынос прерывания в отдельный поток повышает производительность, а не отзывчивость.

Прежде всего он повышает именно отзывчивость.

Ну да, вот, дожили, наконец-то.

> У меня почему есть радостная идиотская уверенность что с исчезновением BKL исчезнет и 12309.

Ни фига. Я еще с .37 ядра собираю без BKL, так как ни одна из железок, которые в моем ноуте есть или в ноут можно воткнуть, его не требуют.

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

Ага, половина разновидностей рипа оказалось быстрее линукса)

Ничего, мы будем троллить рип его Giant Kernel Lock.

В линуксе он был просто большой, а тут — и вовсе гигантский!

ЗЫ. Бтрфс ни нужон. И вообще могли бы сделать его распределенным.

> реализована обработка практически всех прерываний в отдельных потоках;

Linux черпает вдохновение от микроядер?

Это нормальная практика и для модульных ядер.

Соберу, чего уж. Может ath9k перестанет иногда глючить и 12309 будет не таким сильным. Хотя сомневаюсь, но можно попробовать.

Ура! Собрала, установила - работает. Впечатления пока что субъективно сугубо положительные, в gnome3 эффекты стали плавненькими и быстрыми, и тукскарт на старенькой ATI стал работать нормально. Осталось дождаться релиза Fedora 15 и подсунуть ей ядро 2.6.39 :-)

но не любая ОС при нехватке RAM выходит из полнейшего ступора...

Не дай Бог ещё больший глюкодром, чем 38е

А что-нибудь полезное вы умеете делать?

Нет, только эти 2 скила.

To be honest, в Фре я вижу такое при загрузке:

atkb0: [GIANT-LOCKED] psm0: [GIANT-LOCKED]

Так что лялих прям таки крут если они совсем-совсем вырезали весь BKL)

Есть такое. Не полностью ещё избавились.

Хотя ввод вряд ли хоть как-то критичен.