Вышло ядро Linux 2.6.39

>Простой тест из сабжевого коммита намекает, что слово «очень» здесь лишнее, а «дорогая» - сомнительно.

Так там как раз тест на производительность, разве нет? ;)

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

Они предназначены для RT — когда крутится высокоприоритетная задача, и на некоторые устройства можно забить. Когда задаче одно из этих устройств понадобится, она повиснет на мютексе; и за счет динамичесткого поднятия приоритета, устройство разбудится и прочихается (приоритет его треда на некоторое время поднимется до приоритета задачи). Тут конечно, возможны варианты, но в целом так.

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

Если он не закрывает прерывания, то он может вытесниться/прерваться как в случае треда, так и обычного прерывания.

>Быстро наверное это было? :)

Лет 6-7 назад. Дискета и сейчас лежит, если не размагнитилась.

У меня года полтора или два на 16.

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

Не. У меня флеха одна из первых на 16 — на запись великий тормоз, читает более-менее нормально.

//Аву старую поставь, там круче была :)

> Так там как раз тест на производительность, разве нет? ;)

Насколько я понял, там тест, обрабатывающий кучу прерываний :) Если обработка стала бы заметно дороже, тест бы просел.

Они предназначены [..]

Да я знаю, сам занимаюсь RT.

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

Если он не закрывает прерывания, то он может вытесниться/прерваться как в случае треда, так и обычного прерывания.

ЕМНИП, в случае «обычного прерывания» - только другим прерыванием более высокого приоритета.

Ждём обновления main tree на предмет pf-sources 2.6.39.

sys-kernel/gentoo-sources-2.6.39 уже в дереве

Можешь слить с гита то, что есть. Там без TuxOnIce.

> Можешь слить с гита то, что есть. Там без TuxOnIce.

Спасибо, но мне пока не к спеху.

>Реализация таймера CLOCK_BOOTTIME, позволяющего организовать автоматический выход системы из спящего режима в определенное время;

не нашёл в конфиге.

># произведены улучшения в драйвере видеокарт Intel;

Это хорошо для меня.

>И где оно жирнее?

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

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

Тебе зачем?

Не надо про «любое» и «плотное». Конкретную последовательность команд или действий, пожалуйста.

На самом деле, при любом плотном обращении к диску - например, копирование файлов,

Из этой фразы что не ясно?

> Попадёт. Но только с очень большим опозданием.

14я до упора сидит на .35. Скорее всего 15я тоже будет на .38 до конца.

Вылезай из криокамеры. Давно работает, правда опорную частоту всё равно приходится выставлять вручную.

> Вылезай из криокамеры.

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

http://www.alsa-project.org/main/index.php/Matrix:Vendor-Creative_Labs

NOT SUPPORTED YET, but Emu have supplied hardware sample and datasheets to the developer.

Который год там

И абсолютно незаметным оказался патч, ускоряющий acl_permission_check нв 30% по тестам Линуса. На его задачах это дало около 0,5% прироста общей производительности: https://lkml.org/lkml/2011/5/13/298

Список давно не обновлялся. Если пройти по ссылке в комментарии к 0404 usb, то сообщение на форуме об успешной работе датировано January 30th, 2010.

Я мучал с (кажется) 35-го по 37-е ядро на ноуте. Были десятки внезапных отключений питания, том держался, но в итоге всё-таки сдох - не монтируется. Так как ничего важного на этой машине не хранится, а важное было забекплено, пока перешёл обратно на ext4, но битый том сохранил для экспериментов с btrfsck. В рассылке в таких случаях рекомендуют btrfs-select-super и btrfsck из ветки next гита btrfs. С прошлой недели тулзы лежат собранные рядом с тем самым образом, но руки пока не дошли проверить, поможет ли.

А как дела у btrfs с бэд-блоками? Он уже понимает что это такое?

ubuntuforums.org — не совсем то, что хотелось бы видеть, если только думаешь о приобретении. Хотя с инфой о, например, dr. dac все еще хуже, её там вообще нет.

С этим согласен. Отсутствие актуального списка поддерживаемого оборудования ставит в тупик при рассмотрении вариантов. С 36м ядром 0404 usb завелась с ядерными модулем snd-usb-audio, ничего не пришлось патчить. С более ранними ядрами просто не пробовал. Дистр генту, нестабильная ветка.

Спасибо.

> Тебе зачем?

Хочу увидеть подробности проблемы, и исправить, если она есть. От этого и мне и другим станет лучше. Или в очередной раз убедиться, что 12309 - это пустой треп.

Из этой фразы что не ясно?

Из этой фразы не ясно, какая именно команда выполняется для воспроизведения бага. В результате складывается впечатление что ты сам не знаешь, как его воспроизвести, но тебе кто-то рассказывал, что оно таки как-то где-то есть если что-то сделать...

Хочу увидеть подробности проблемы, и исправить, если она есть.

Хотеть не вредно. Ты - разработчик модулей/самого ядра? У тебя достаточно компетенции? Если да, то вылечи, сначала, ядро от падения за счет юзерспейс программ. Потом продолжим.

Из этой фразы не ясно, какая именно команда выполняется для воспроизведения бага.

Ты чухонец, что-ли? Русским языком говорю - любая команда копирования. В результате, складывается впечатление, что ты - задрот! Прости, конечно!

> Если да, то вылечи, сначала, ядро от падения за счет юзерспейс программ.

Пруф или GTFO.

Пруф чего? Что юзерспейс программа рубит ядро?

хэй всё пучком на 38 с потреблением.. (если тока в убунте чё прикрутили..)

вылечи, сначала, ядро от падения за счет юзерспейс программ.

Каких программ? Давай подробности.

Русским языком говорю - любая команда копирования.

Копирования откуда и куда? Или для тебя будет открытием узнать, что ввод-вывод сам по себе часто не быстрый?

Ничего не понял. Но на заметку взял.

Каких программ? Давай подробности.

Chrominium daily, в ряде случаев FF. На Side и на Ubuntu LTS.

Копирования откуда и куда?

С винта на тот же винт, с винта на сеть, с винта на usb (а также и e-sata) винт.

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

Вот это ты что сейчас сказал?

Chrominium daily, в ряде случаев FF. На Side и на Ubuntu LTS.

На твоём месте стоит задуматься над проверкой железа. Я линукс на десктопе с 1997г использую, ежедневно для дома и работы. На работе сервера и десктопы, дома на ноуте и на десктопе. Подобные программы тоже есть, сейчас с дебиана перешёл на Ubuntu. То, о чём ты говоришь, может быть проблемой железа и/или драйверов. В целом к «падению ядра от юзерспейс программ» это никак не относится.

С винта на тот же винт, с винта на сеть, с винта на usb (а также и e-sata) винт.

Вот тут я перестаю понимать. Это много разных случаев, зависящих от многих обстоятельств. Когда я копирую с винта на винт/другой винт, у меня всё предсказуемо работает, с сетью тоже. Нужен конкретный способ воспроизведения бага. Какой винт, модель, что про него в dmesg сказано, какая файловая система на нём, как фрагментировано место, сколько памяти, какой контроллер, используется ли криптование и пр. И это только один случай. В дисковой подсистеме линукса я знаю ровно одно узкое место — криптование.

Вот это ты что сейчас сказал?

Я сказал, что не понимаю сути твоих претензий. Так можно дойти до вопроса: «господи, ну почему я родился не девочкой» — или подобного бессмысленного.

На твоём месте стоит задуматься над проверкой железа.

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

«Проблема» воспроизводилась со 100% повторяемостью - запускал хроминиум (далее, хром) - на определённом сайте «вышибало» в ребут. После очередного апдейта хрома проблема исчезла. Да и писали о ней, насколько помню. Примерно 6-8 месяцев назад было. Дебиан Сид.

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

Какой винт, модель, что про него в dmesg сказано, какая файловая система на нём, как фрагментировано место, сколько памяти, какой контроллер, используется ли криптование и пр. И это только один случай.

Да тут всё просто: винт sata-нубучный, 250ГБ, ext3, места - полно (половина точно), памяти 4ГБ, ICH8 (на него и грешу), крипта - нет.

Я, кстати, и не утверждаю, что 12309 - чисто софтовая бага, есть неприятные подозрения о чипсетах Intelя.

>//Аву старую поставь, там круче была :)

До этой у меня была такая же, потом несколько часов такая же, но с анимацией. Не хочешь сам, на своём скоре, проверить терпение и наблюдательность модераторов;) Если что, в ИЕ анимации вроде как не видно, может и в телефонах тоже.

Вопрос попробовавшим: нормальный патч для vmware уже изобрели, или оно на .39 не работает? В гугле пишут, что хотя патч есть, он приводит к OOPS :(

> Русским языком говорю - любая команда копирования.

Ок. Выполняю команду dd if=/dev/sda of=/dev/null - сойдет за «любую»? Запущенные программы работают как и раньше, мыша двигается, окна перетаскиваются, ничего не тормозит. Бага нет.

У тебя есть? Лично у тебя? Тогда ты и выполни эту «любую команду», и укажи, какую команду ты выполнил, добавь к ней содержимое /proc/interrupts до и после выполнения этой команды, а также вывод `vmstat 1` во время. Тогда и посмотрим, есть ли баг на самом деле, или нет.

А так - команды ты не назвал, логов не выложил, только треп. Это лишний раз подтверждает, что проблема выдумана.

> Выполняю команду dd if=/dev/sda of=/dev/null - сойдет за «любую»?

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

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

На какой ФС? Что является критерием fail? На моём десктопе есть XFS и Ext4, торренты и музыка на Ext4, всё на крипторазделах. Реально DeadBeef заикается только при аллокации места под новый торрент на несколько гигабайт. Когда не было криптораздела, проблема была ещё меньше.

>> Нет, данные должны записываться на реальный носитель.

На какой ФС?

В репортах фигурирует ext3, но, подозреваю, тип ФС не играет особой роли.

Что является критерием fail?

Отсуствие реакции курсора мыши на передвижение, остановка проигрываемой музыки.

> Нет, данные должны записываться на реальный носитель.

А `dd if=/dev/urandom of=/path/file` приводит к появлению бага?

> А `dd if=/dev/urandom of=/path/file` приводит к появлению бага?

Попробуй.

Баг хорошо воспроизводился по dd if=/dev/zero of=~/file bs=100M Т.е. быстрый источник и большой объем буфера.

Отсуствие реакции курсора мыши на передвижение, остановка проигрываемой музыки.

Не хватает вводных данных. Например, у меня ktorrent аллоцирует место на диске под новый торрент разом, чтобы потом не было дефрагментации. По iostat я вижу, что на винт при этом постоянно пишется со скоростью примерно 70мб/сек. Я так понимаю, это подходит под описание dd if=/dev/zero of=/real/file? В момент, когда он выполняет аллокацию, иногда заикается DeadBeef, который играет lossless с того же раздела. Плюс это усугубляется криптованием. Никаких проблем с мышкой и остальными программами. Более того, с переходом на 2.6.38, со включенным autogroup, я уже забыл когда последний раз заикался DeadBeef при подобной операции. При проигрывании музыки с другого раздела и вообще при операциях с другими разделами при этом нет никаких задержек. Поэтому, необходимо точное описание методики и описание обстоятельств проблемы, а так же критерии, которые на неё указывают. А то «тормозит копирование» — откуда мне знать скорости носителей и пр?

Баг хорошо воспроизводился по dd if=/dev/zero of=~/file bs=100M Т.е. быстрый источник и большой объем буфера.

Эта команда забивает целиком раздел кусками по 100мб. Ерунда какая-то.

>> Баг хорошо воспроизводился по dd if=/dev/zero of=~/file bs=100M Т.е. быстрый источник и большой объем буфера.

У меня не воспроизводится :) iowait до 35% следует считать высоким при такой операции? Поток при этом пишется на два физических диска одновременно.

>> Ерунда какая-то.

Знакомься: https://bugzilla.kernel.org/show_bug.cgi?id=12309

Эта команда забивает целиком раздел кусками по 100мб. Ерунда какая-то.

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

У меня не воспроизводится :) iowait до 35% следует считать высоким при такой операции? Поток при этом пишется на два физических диска одновременно.

Критерий воспроизводимости - тормоза, а не какие-то циферьки.

>> Отсуствие реакции курсора мыши на передвижение, остановка проигрываемой музыки.

Не хватает вводных данных.

Да говори уже сразу «нужен точный рецепт воспроизведения бага». Так вот, если бы такой рецепт был, баг починили бы очень давно.

с переходом на 2.6.38, со включенным autogroup

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

Да говори уже сразу «нужен точный рецепт воспроизведения бага». Так вот, если бы такой рецепт был, баг починили бы очень давно.

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

Критерий воспроизводимости - тормоза, а не какие-то циферьки.

Ну, тормоза должны вроде сопровождаться высоким iowait. Посмотрел сейчас тред 12309 в багзилле — там фигурируют «циферьки» от 70 до 100%.