LINUX.ORG.RU

Ядро Linux 3.2 получило статус длительной поддержки (LTS)

 , , ,


0

1

22 апреля 2012 года Грег Кроа-Хартман (Greg Kroah-Hartman) сообщил о выходе ядра 3.2.16. В этом же сообщении он известил, что это последний релиз ветки 3.2, который он поддерживал, в дальнейшем поддержку ветки 3.2 будет осуществлять Бен Хатчингс (Ben Hutchings).

Бен Хатчингс (Ben Hutchings) в свою очередь сообщил, что ядро версии 3.2 получает статус долговременной поддержки (long-term support). Однако не уточнил, как долго будет осуществляться такая поддержка.

Ранее Бен Хатчингс (Ben Hutchings) уже сообщал, что предстоящий релиз Debian 7.0 Wheezy будет использовать ядро версии 3.2.

Ядро реального времени для Debian Wheezy также будет основано на версии 3.2. Об этом сообщил его разработчик Стивен Ростедт (Steven Rostedt).

Ожидается, что Бен Хатчингс (Ben Hutchings) будет поддерживать ядро версии 3.2 до окончания жизненного цикла Debian 7.0 Wheezy.

Кроме Debian 7.0 Wheezy ядро версии 3.2 используется в вышедшей в конце апреля Ubuntu 12.04 LTS, для которой срок поддержки заявлен в пять лет.

>>> Подробности



Проверено: post-factum ()
Последнее исправление: doluphio (всего исправлений: 2)
Ответ на: комментарий от holka

Че, правда? Тогда винде точно капец! у нас же багов не осталось кроме #1.

AlexCones ★★★
()
Ответ на: комментарий от holka

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

anonymous
()
Ответ на: комментарий от holka

Они вообще 3.0 сначала хотели

Да что вы с ним так возитесь, ума не приложу.

kost-bebix ★★
()
Ответ на: комментарий от true_admin

> В 3.3 12309 пофиксили же

этот баг будет жить вечно

Ну да. В линуксе две беды - kernel API nonsence и неосиляторы. А 12309 это не третья беда линукса, а следствие из второй :-)

no-dashi ★★★★★
()
Ответ на: комментарий от tailgunner

как его воспроизвести.

В багзилле всё написано. В любом случае позиция «если у тебя есть этот баг то ты лох и неосилятор» тупа.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

как его воспроизвести.

В багзилле всё написано.

В багзилле под этим номером - куча багов. Некоторые «рецепты воспроизведенеия» просто должны ставить тачку на колени. Но, в любом случае, первый рецепт уже на 3.0 не имеет последствий, описанных в багзилле (только что попробовал его на дебиановском 2.6.26 из Lenny - тоже не вижу описываемых в багзилле симптомов; по ощущениям, оно даже лучше 3.0).

позиция «если у тебя есть этот баг то ты лох и неосилятор» тупа.

Позиция «если у тебя есть этот баг - ты лжец и/или паникер» более близка к истине, кмк.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Расскажи, как его воспроизвести.

tmps 50% от общего объема озу, своп в файл, сборка chromium - уже через пятнадцать минут система становится неюзабельна.
Но если отключить своп (можно в процессе сборки хромого), то все становится хорошо. Только киллер у меня лису в этот момент прибивает.

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

tmps 50% от общего объема озу, своп в файл, сборка chromium - уже через пятнадцать минут система становится неюзабельна.

Сборка на tmpfs? С каким -j? Сколько памяти? Сколько свопа?

tailgunner ★★★★★
()
Ответ на: комментарий от true_admin

ну расскажи мне сказку как ты осилил этот баг

Для начала, я попробую угадать - этот «баг» у тебя происходит в момент копирования большого файла (больше объема свободной RAM), и залючается в том, что переключение между задачами (а перемещение мыша - это переключение между задачами - куда по твоему летят события mouse_move?) становится «равным» и дерганым?

Это не баг, это тривиальная нехватка полосы пропускания. Лечится хреновой тысячей способов, от планирования I/O - типа установки и использования отдельного привода (или SSD) под систему (вообще устраняет проблему как класс), удержания достаточного объема свободного места на разделах с данными (избавляет от медленного чтения), и заканчивая воркэраундами типа принудительного кэширования библиотек и бинарников (избавляет от дерганий уже загруженых приложений и облегчает запуск новых, значительно снижая визуальность «тормозов»).

И ещё раз - это не баг, это нормальное поведение несбалансированной инсталяции а.к.а. «руки из жопы». Да, построение сбалансированной системы отнюдь не так просто. И инсталяция как её привыкли делать ЛОР-овцы отнюдь не всегда правильная. И именно поэтому одни (до чьего моска «не дотумкало») будут кричать про 12309, а другие, кому повезло тем или иным способом - например, система не выбирает весь I/O или стоит SSSD, или кого интуиция подвинула сделать правильно будут также говорить «да нет никакого бага, хватит пороть херню».

no-dashi ★★★★★
()
Ответ на: комментарий от andreyu

tmps 50% от общего объема озу, своп в файл

... а яйца дверью зажимать не пробовал? Если у тебя контент tmpfs вытеснил нафиг всё в своп, чего ты ещё ожидал получить?

no-dashi ★★★★★
()
Ответ на: комментарий от andreyu

Сборка на tmpfs? С каким -j? Сколько памяти? Сколько свопа?

-j9, памяти 4 гб, своп 5 гб.

У тебя банальный thrashing, который является _штатным_ поведением системы с виртуальной памятью.

tailgunner ★★★★★
()
Ответ на: комментарий от no-dashi

И ещё раз - это не баг, это нормальное поведение несбалансированной инсталяции

А вот это уже можно считать багом. Наличие ЗУ с разной скоростью записи - нормальная ситуация, и система должна обрабатывать ее корректно: https://lwn.net/Articles/405076/ https://lwn.net/Articles/456904/

tailgunner ★★★★★
()
Ответ на: комментарий от no-dashi

... а яйца дверью зажимать не пробовал?

Кому?

Если у тебя контент tmpfs вытеснил нафиг всё в своп, чего ты ещё ожидал получить?

Читайте внимательно, отключение swap решало проблему. Исходя из этого я делаю вывод, что ядро все еще неразумно работает.

andreyu ★★★★★
()
Ответ на: комментарий от tailgunner

У тебя банальный thrashing, который является _штатным_ поведением системы с виртуальной памятью.

Ну и какое вы предлагаете решение?

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

У тебя банальный thrashing, который является _штатным_ поведением системы с виртуальной памятью.

Ну и какое вы предлагаете решение?

Я бы тупо отключил tmpfs и увеличил swap. Возможно, еще бы уменьшил -j.

P.S. использование tmpfs ускорения работы - обычно очень плохая идея.

tailgunner ★★★★★
()
Ответ на: комментарий от no-dashi

А ты сделай объем tmpfs в 30% объема RAM и потом расскажи нам о результатах.

Обоснуйте. Пока ваше предложение похоже на предложение Брежнева из анекдота.

andreyu ★★★★★
()
Ответ на: комментарий от no-dashi

У меня вообще этого бага нет. Я просто держу в памяти многолетнюю историю этот проблемы и не спешу с выводами. Если у тебя этого нет это не значит что у других нет. В багзилле активность минимальная, понять ушла проблема или затаилась по ней нельзя.

А про суть проблемы я в курсе. Только дело не в полосе пропускания а в том что при попытке записи повисают все задачи во время сброса грязных страниц на диск.

true_admin ★★★★★
()
Ответ на: комментарий от tailgunner

Я бы тупо отключил tmpfs и увеличил swap. Возможно, еще бы уменьшил -j.

Ну про tmpfs несколько мнений - кто то говорит, что это хорошо, а кто то плохо. Думаю, что от сценария зависит.
У меня 8 ядер (четыре честных, 4 благодаря ht), посему и стоит -j9. Может и стоит еще раз попробовать отключить ht и сделать -j5.

P.S. использование tmpfs ускорения работы - обычно очень плохая идея.

Почему? Диск то меньше дергается.

andreyu ★★★★★
()
Ответ на: комментарий от holka

Кстати, а больше нигде не осталось 12309 на новых ядрах? Когда он впервые появился? Как долго просуществовал?

CYB3R ★★★★★
()
Ответ на: комментарий от andreyu

Ну про tmpfs несколько мнений - кто то говорит, что это хорошо, а кто то плохо.

Интересно было бы узнать доводы тех, кто говорит «это хорошо».

использование tmpfs ускорения работы - обычно очень плохая идея.

Почему?

Потому что оставляет VMM меньше места для маневра. Если ты распаковал на нее сорцы, ты тем самым уменьшил объем памяти, доступной для рабочей нагрузки (компиляции).

Диск то меньше дергается.

Иллюзия. Данные обычных ФС кэшируются почти так же эффективно, как и tmpfs, но при этом их можно сбросить на внешний носитель (или просто похерить).

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

не скажи. Гентушникам tmpfs к примеру очень важен - для /var/tmp/portage например. Нахрена мне сбрасывать на винт временные объектные файлы, генерируемые при сборке пакетов?

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Гентушникам tmpfs к примеру очень важен - для /var/tmp/portage например. Нахрена мне сбрасывать на винт временные объектные файлы

Чтобы не поддерживать миф 12309.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Иллюзия. Данные обычных ФС кэшируются почти так же эффективно, как и tmpfs, но при этом их можно сбросить на внешний носитель (или просто похерить).

Довод принят. Сча отключу tmpfs.

andreyu ★★★★★
()
Ответ на: комментарий от tailgunner

Чтобы не поддерживать миф 12309.

Кстати да:

# du -sh /var/tmp/portage/
1.2G	/var/tmp/portage/
andreyu ★★★★★
()
Ответ на: комментарий от true_admin

это вообще не баг это миф. причём скорее всего очень железоспецифичный и кроме как тюнингом поведения под оборудование не решится.

Thero ★★★★★
()
Ответ на: комментарий от Thero

это вообще не баг это миф.

это не миф, это то с чем я столкнулся и с чем доолго боролся.

скорее всего очень железоспецифичный

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

true_admin ★★★★★
()
Ответ на: комментарий от andreyu

Читайте внимательно, отключение swap решало проблему.

Мм, а может это был АХСИ планировщик южного моста или самого ЖД? ;-)

anonymous
()
Ответ на: комментарий от Adjkru

Блин.. А у вас ядро самосборное? Я свое деолго точил, сильно отличается от дефолтов. У меня раньше были проблемы с записью на флешки больших файлов, теперь решились сами собой. И вот.

holka
()
Ответ на: комментарий от tailgunner

Да нахрен 12309! Я говорю о том, что зачем хранить ВРЕМЕННЫЕ файлы на винте, если это можно делать в оперативе? Не, если той оперативы кот наплакал - вопросов нет. Но у меня дома стоит 12 гигов(ну люблю я гонять тучи виртуалок, да). Так что смысла я не вижу - с 6 гигами tmpfs не собирается разве что libreoffice, который я все равно ставлю из бинарного пакета...

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Я говорю о том, что зачем хранить ВРЕМЕННЫЕ файлы на винте, если это можно делать в оперативе?

А зачем вообще собирать софт самому, если у тебя избыток ресурсов и выигрыша ты даже не заметишь?

Не, если той оперативы кот наплакал - вопросов нет. Но у меня дома стоит 12 гигов

Если тебе некуда девать память - да, tmpfs тебе поможет.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

если у тебя избыток ресурсов и выигрыша ты даже не заметишь?

если у меня много ресурсов, то это не значит что можно забить на оптимизацию, потому что:

1) я часто нагружаю комп под завязку, и не только компиляцией; 2) поверь, прямые руки + правильные флаги сборки дают выйгрыш в производительности отдельных часто-используемых операций гораздо выше чем 1%(у меня это вариируется от 5 до 10%) - для меня это существенно. Главное - не переусердствовать. Золотая середина красноглазия должна быть...

Pinkbyte ★★★★★
()
Ответ на: комментарий от anonymous

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.