LINUX.ORG.RU
Новости — Ядро Linux  

Выпущено ядро Linux 2.6.36

 ,


0

2

Состоялся выпуск новой версии ядра Linux версии 2.6.36. Её разработка длилась 80 дней, за это время в ядре произошли следующие изменения:

  • добавлена подсистема безопасности AppArmor;
  • переработана подсистема VFS в плане распараллеливания работы;
  • переписан механизм OOM, позволяющий ядру вести себя более корректно при нехватке памяти;
  • добавлена поддержка Intel Intelligent Power Sharing support (касается управления питанием на платформах Intel Core i3/5 с интегрированной графикой);
  • отладчик KGDB интегрирован с подсистемой KMS. Дебажить теперь стало ещё проще;
  • добавлена поддержка процессоров Tilera;

Как результат некоторой пачки изменений, планируется, что улучшится отзывчивость системы в целом.

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

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

>>> Официальный анонс

★★★★★

Проверено: maxcom ()
Последнее исправление: Casus (всего исправлений: 1)

 ← 1 2 3 4 5 6 →

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

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

> Ура, apparmor стал мейнстримом :). Интересно сколько мне людей напишет что он не нужен(например, из-за того что метки на уровне фс не держит), что selinux наше всио? :)

selinux так и не осилил. Хочу tomoyo посмотреть.

turtle_bazon ★★★★★
()

Очень интересно, как это корректно теперь будет вести себя ядро при нехватке памяти? Когда то наступил на грабли, понядеевшись на то, что malloc вернет NULL, если нехватает СВОБОДНОЙ памяти, но вместо этого ядро успешно выносит все процессы под чистую, но упорно пытается выделить память приложению (свап был отключен, думал 4Гб хватит абсолютно на все). И вот как с этим то жить дальше?

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

что угодно, только не такое УГ под названием selinux :) оно defective by design.

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

> И вот как с этим то жить дальше?

Почитай про kernel's overcommit settings. Собственно malloc выделяет виртуальную память, возвращая указатель. Физической памяти может и не хватить.

Можно самому проверять память перед выделением.

praseodim ★★★★★
()

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

postrediori
()
Ответ на: комментарий от Pavval

> Нну. Поставил я твои smp_affinity. Стало мне лучше? Хрен там. Повторюсь: сабж-rc3 почти поправил проблему, но все-таки она немного еще есть. А вот irq affinity нифига не меняет.

Тогда можно узнать симптомы той «проблемы», которую почти поправил сабж-rc3?

На всякий случай, симптомы «бага» 12309: при большом количестве I/O-операций даже курсор мыши замирает или двигается рывками, и сами эти I/O-операции выполняются медленнее, чем должны (например, скорость записи на «быструю» флешку - меньше 1 мегабайт/c вместо ~10МБайт/сек).

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

>Пруф?
мой локалхост
просто подумай - упаковка хвостов - это лишнее телодвижение - отсюда тормоза
проверено лично мной - поэтому notail!

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

тест будет?
как узреть попугаев, чоб мерить?

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

>>Чтение должно ускориться

чтение то может быть, а вот запись...


Поищи тесты производительности. Увидишь, что теоретизировать нет причин, а производительность очень неплохая.

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

>Тогда можно узнать симптомы той «проблемы», которую почти поправил сабж-rc3?

А как ты думаешь? dd if=/dev/zero of=file bs=2G уводил систему в аут. Сейчас слабее общий эффект и почти исчезли подтормаживания мыши. Скорость I/O нареканий как не вызывала, так и не вызывает.

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

Для корня таки лучше высокая скорость чтения.
Я на ext2 перешёл - если что, бэкап ~5минут разворачивать всего ;)

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

> А как ты думаешь? dd if=/dev/zero of=file bs=2G уводил систему в аут. Сейчас слабее общий эффект и почти исчезли подтормаживания мыши. Скорость I/O нареканий как не вызывала, так и не вызывает.

Гыгы. Я думаю, копировать блоками по ДВА ГИГАБАЙТА. А где по-твоему dd будет хранить ДВУХГИГОБАЙТОВЫЙ буфер? В памяти, ага. Такой dd элементарно съедает всю память и, если своп есть, загоняет систему в своп. :) Это не 12309, это - бред запускающего.

Да, если какая-то программа сжирает всю память, то система начинает тормозить. И это - не баг.

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

> Тут проблема в том, что 12309 и на одноядерниках проявляется.

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

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

dd if=/dev/zero of=111 bs=1G, например.
Курсор останавливается, окна переключаются с задержкой.
2G ram, свопа нет, примерно одинаково с cfq и ncq+noop.
При обычной работе с диском не так сильно проявляется, но мешает.

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

>Да, если какая-то программа сжирает всю память, то система начинает тормозить.

Нет, даже если free ram значительно больше размера блока, всё равно так.

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

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

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

там ничего интересного!
рейзеру сливает в любом случае
есть такой фс на файло помойке - гавно гавном (/var)

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

>Гыгы. Я думаю, копировать блоками по ДВА ГИГАБАЙТА. А где по-твоему dd будет хранить ДВУХГИГОБАЙТОВЫЙ буфер? В памяти, ага. Такой dd элементарно съедает всю память и, если своп есть, загоняет систему в своп. :) Это не 12309, это - бред запускающего.

Гыгыкай дальше. У меня 6Гб памяти, из которых как правило 5 свободно. Еще бред с твоей стороны будет?

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

>там ничего интересного!

Да ты упоролся.
С корня 99% времени происходит только чтение, причём мелких файлов.
По этому параметру из стабильных фс лучше чем ext2 только squashfs.
На скорость записи можно положить.

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

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

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

Вот именно, что не надо - у меня корень пакуется в tar быстрее всего на ext2.
Сквош не пробовал, но говорят, для /usr быстр.

anon_666 ★
()

Выпущено ядро Linux 2.6.36

Эх, а обещали добавить reiser4 в 36-е ядро... ((

Luntik
()

мда, вот и история успеха. поставил на лаптопе и получил перманентный фриз на 2-3-й секунде запуска, даже modeset еще не сработал.

registrant ★★★★★
()
Ответ на: комментарий от val-amart

хм...спасибо :)
на одного неадеквата мой лор стал чище

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

Похоже с irqbalance и правда стало заметно лучше. Субъективно раньше ресторы больших бекапов в постгрес проходили заметно тяжелее для системы, а сейчас подвисаний iceweasel не заметил.
Добра тебе, анон!

anonymous
()

блин, iwlagn на карточке «Intel Corporation WiFi Link 1000 Series» намертво вешает систему, сцуко((
на 2.6.35-gentoo-r11 (предыдущие не знаю, ноут новый) оно просто кидало раз в полчаса в dmesg вот такое: «kernel: iwlagn 0000:03:00.0: Microcode SW error detected. Restarting 0x82000000.», перегружало фирмварь и успешно работало себе дальше, даже соединение не рвалось, а тут тупо валит в кернел-паник, чтоб ему...

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

>реально 0!

4.2, сходу профит +92.5% против ext2, которая быстрее твоего женоубийцы.
У тебя адово фрагментирована фс.

http://www.linux.org.ru/jump-message.jsp?msgid=5453261&cid=5476738

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

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

>4.2, сходу профит +92.5% против ext2, которая быстрее твоего женоубийцы.

ext2, которая быстрее твоего женоубийцы.


4.2 потому что женоубийца-4 имеет сжатие жены и потому быстрее.

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

Неа, во-первых я на работе под виндой, а во-вторых мне влом сравнивать фс. Когда-то, когда будет время, займусь из интереса. Так что я исключительно теоретизирую:)

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

>ext2, которая быстрее твоего женоубийцы.
ложь!

megabaks ★★★★
()
Ответ на: комментарий от anon_666 
desktop megabaks # hdparm -t /dev/sda4 /dev/sda2

/dev/sda4:
 Timing buffered disk reads: 266 MB in  3.01 seconds =  88.47 MB/sec

/dev/sda2:
 Timing buffered disk reads: 278 MB in  3.02 seconds =  92.10 MB/sec
desktop megabaks # echo 3 > /proc/sys/vm/drop_caches 
desktop megabaks # dd if=/dev/zero of=/var/tmp/test bs=1KB count=1000000
1000000+0 записей считано
1000000+0 записей написано
 скопировано 1000000000 байт (1,0 GB), 15,3439 c, 65,2 MB/c
desktop megabaks # echo 3 > /proc/sys/vm/drop_caches 
desktop megabaks # dd if=/dev/zero of=/var/tmp/test bs=1KB count=1000000
1000000+0 записей считано
1000000+0 записей написано
 скопировано 1000000000 байт (1,0 GB), 14,6536 c, 68,2 MB/c
desktop megabaks # echo 3 > /proc/sys/vm/drop_caches 
desktop megabaks # dd if=/dev/zero of=/test bs=1KB count=1000000
1000000+0 записей считано
1000000+0 записей написано
 скопировано 1000000000 байт (1,0 GB), 12,8985 c, 77,5 MB/c
desktop megabaks # echo 3 > /proc/sys/vm/drop_caches 
desktop megabaks # dd if=/dev/zero of=/test bs=1KB count=1000000
1000000+0 записей считано
1000000+0 записей написано
 скопировано 1000000000 байт (1,0 GB), 12,0654 c, 82,9 MB/c
desktop megabaks #

/var - это ext2 на sda4
/ - это reiserfs на sda2
по данным hdparm раздел с /var выжимает 96% от скорости корня
а запись файла мелкими кусками на /var выжимает всего 83% от скорости корня
вопросы?
кстати погугли тесты фс Крона - узнаешь много нового :)

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

Кстати, вдогонку к .36.
Тут в свежем -git добавили CONFIG_BKL (big kernel lock).
скоро можно будет без него собирать.

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

>/var - это ext2 на sda4

/ - это reiserfs на sda2

На разных разделах? Ты с фороникса?

а запись файла

Меня не интересует, разговор был про чтение.

запись файла мелкими кусками

Не видишь разницы между мелкими файлами и работой с одним большим но мелкими блоками? Сёрьёзно?

кстати погугли тесты фс Крона - узнаешь много нового :)

Уже все их перечитал.

вопросы?

Упоролся?

ext2, которая быстрее твоего женоубийцы.

ложь!

Нет, пруфы:
http://www.linux.org.ru/forum/general/5453261
http://www.linux.org.ru/jump-message.jsp?msgid=5453261&cid=5453672

anon_666 ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6 →
Ядро Linux