LINUX.ORG.RU

Вышло ядро Linux 3.8

 ,


3

2

После двух месяцев разработки вышла новая версия ядра Linux 3.8.

Основные новшества представлены ниже.

  • В файловых системах и подсистеме хранения данных.
    • Добавлена поддержка файловой системы F2fs, предназначенной для использования на USB-флешках, картах памяти и других устройствах, использующих уровень FTL. Принцип действия этой ФС основан на постепенном заполнении носителя с начала устройства (Log-structured FS), при этом используется приём Copy-On-Write. ФС гарантирует доступность старых данных, если новые данные записаны не полностью, при этом традиционное (для некоторых систем) журналирование не используется за ненадобностью.
    • В btrfs улучшена функция переноса данных с одного диска на другой. Помимо этого, в код этой ФС приняты патчи, позволяющие некоторым алгоритмам распараллеливаться на несколько процессоров (ядер), что в теории должно привести к увеличению производительности.
    • В файловой системе Ext4 реализована поддержка хранения мелких файлов непосредственно в inode. Этот приём используется для убыстрения доступа к таким файлам, а также в целях экономии дискового пространства. Напомним, что похожие алгоритмы используются и в reiserfs.
    • В файловой системе XFS реализована функция определения повреждений метаданных при выполнении операций чтения и записи. Такие повреждения выявляются посредством вычисления контрольных сумм по алгоритму CRC.
    • В код подсистемы, отвечающей за реализацию RAID6, добавлена поддержка инструкций AVX2, что позволит повысить производительность некоторых операций на будущих процессорах Intel Haswell.
  • В инфраструктуре.
    • Добавлена возможность ограничения памяти ядра, используемой для управления процессами. Это позволяет более эффективно бороться с т.н. форк-бомбами, т.е., бесконтрольным размножением процессов.
    • Подсистема NUMA изменена таким образом, чтобы поддерживать когерентность между памятью и процессором для одного процесса. Это должно привести к повышению быстродействия, т.к. процессы на архитектуре NUMA быстрее получают доступ к памяти, выделенной своему процессору, нежели другим.
    • В отдельных случаях значительно уменьшено потребление памяти. В случае, если процесс запрашивает много памяти, но не пишет в неё, память реально не выделяется. Это достигнуто благодаря применению техники Copy-On-Write для выделения больших страниц памяти на основе страниц, заполненных нулями.
    • Включена утилита turbostat. Она позволяет на новых процессорах Intel смотреть приблизительное потребление (в ваттах) каждого ядра (вычислительного и графического) по отдельности.
    • Добавлена поддержка динамического изменения объёма выделенной памяти при использовании ядра в виртуализированном окружении Hyper-V.
    • Убрана поддержка процессоров серии 386 с целью упрощения кода, отвечающего за поддержку многопроцессорности.
    • В BPF добавлена возможность фильтрации трафика по VLAN'ам. Эту возможность можно использовать, например, в пользовательской утилите tcpdump.
    • Добавлена поддержка вычисления контрольных сумм инкапсулированных пакетов на уровне «железа», что должно снизить нагрузку на центральный процессор.
    • Планировщик процессов изменён таким образом, чтобы помещать много маленьких заданий на одно ядро процессора, позволяя другим ядрам бездействовать. Также отмечается переработка подсистемы RCU, призванная уменьшить джиттер задержки при перепланировании процессов.
  • В драйверах.
    • В драйвер Nouveau добавлена поддержка 3D-ускорения с помощью OpenGL на всех существующих картах GeForce. По части управления охлаждением и поддержки ускорения видео разработчикам ещё предстоит работать.
    • Добавлен простой графический драйвер для NVIDIA Tegra 2/3, разработанный не в компании NVIDIA. К сожалению, наработки последней по части аппаратного ускорения появились позже и в этот выпуск ядра не попали.
    • Улучшена производительность сетевых драйверов, которые используются для паравиртуализации.
    • Значительно расширен спектр поддерживаемых устройств.

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

Скачать тарболл с исходным кодом

Скачать патч на ядро 3.7

>>> Анонс ядра на LKML

★★★★★

Последнее исправление: post-factum (всего исправлений: 2)

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

Увы, но проги реально аллоцируют _гораздо_ больше памяти, чем используют.

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

Или, если ты замапишь большой файл с MAP_PRIVATE, PROT_READ|PROT_WRITE, то это тоже зачтётся как выделение памяти.

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

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

И что дает эта эвристика ? Повышенную вероятность прихода ООМ ? Ей богу не понятно стоит ли овчинка выделки

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

Напомним, что похожие алгоритмы используются и в reiserfs.

и в ntfs

На что вы намекаете, сэр!!!?

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

А что, reiserfs у нас файлы уже в иноде хранит?

емнип, мелкие файлы и «хвосты» крупных рейзер хранит в инодах.

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

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

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

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

Ну так развивайте мысль, объясните, чем же так мешает.

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

Именно что поможет, если оно писать будет туда не очень много. При этом, размер файла вообще по барабану, хоть терабайт.

И что дает эта эвристика ? Повышенную вероятность прихода ООМ ?
Ей богу не понятно стоит ли овчинка выделки

Повышенную относительно чего? Даёт она лишь одно: возможность использовать _всю_ физ память, даже при относительно маленьком свапе. Это единственное, что она даёт.

anonymous
()

И самое главное для пользователей Sandy / Ivy Bridge и HD3000 / HD4000 забыли: на этом ядре НЕТ ТИРИНГА!

ValdikSS ★★★★★
()

В драйвер Nouveau добавлена поддержка 3D-ускорения с помощью OpenGL на всех существующих картах GeForce.

Сначала хотелось бы производительности в 2D, как в пропиетарных дровах.

P.S. R.I.P. 386...

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

Сначала хотелось бы производительности в 2D, как в пропиетарных дровах.

Предлагаешь затормозить нуво до уровня блоба?

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

Теоретически - да, так как CoW - это механизм, который работает в момент записи в память, а оверкоммит - характеристика механизма аллокации.


Рад что мы друг друга поняли.

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

Рад что мы друг друга поняли.

Кроме отсылки к циферкам в overcommit_memory - да. Впрочем, и это можно на мелочи жизни списать.

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

Ну так развивайте мысль, объясните, чем же так мешает.

Всегда успешно удовлетворять запросы приложения, без оглядки на реально доступны объем виртуальной, означает лишить приложение возможности отреагировать на недостаток памяти самостоятельно. Система забирает ответственность на себя, а недовольных потом ООМ тихо мочит в сортире

Абстрактный пример. Приходите вы в банк с капиталом в 1000$ и просите дать кредит в 2000$. Вариант без оверкоммита - банк говорит, извините не могу дать вам такой кредить, вы переспрашиваете а 500$ - банк говорит держи 500$

Вариант c оверкоммитом - банк говорит, да без проблем, прямо сейчас на карточку 1000$ кинем, а как остальное понадобится так и переведем. И всё - вы не владеете ситуацией. Банк вам наврал и лишил вас инструмента контроля, если они не сможет заработать еще 1000$ ко времени вашего повторного обращения, он будет сам решать, либо разорвать с вами договор в одностороннем порядке, либо вообще устроить дефолт.

Да в некоторых случаях оверкоммит позволяет более эффективно использовать физическую память, но в условиях невозможности увеличения объема виртуальной, а в линуксе размер свопа как правило фиксирован, это русская рулетка. Русская рулетка по умолчанию

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

У меня все-равно несколько пикселей вверху тирит, к сожалению, на xv. Ну и с kwin тоже тирит, т.к. там vsync сделан старым способом, а новый все еще не включили https://git.reviewboard.kde.org/r/107198/

Но это уже намного лучше того, что было.

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

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

Это практически никогда не нужно: на моём опыте, 1 программист из 10 кропотливо проверяет результат malloc() на NULL. Да и тот, кто проверяет, просто ставит assert(), так как делать в условиях отсутствия памяти уже всё равно особо нечего. В то же время, если у вас будет 30% оперативки просто без дела валяться - это катастрофа! Так что смените приоритеты этим двум проблемам, и всё встанет на свои места.

Вариант c оверкоммитом - банк говорит, да без проблем, прямо
сейчас на карточку 1000$ кинем

Блин, вот этот пример вы зря привели. Просто здесь это оффтопик, но я бы вам целую лекцию прочёл о том, как банки и на самом деле оверкоммитят. В кратце: они вам на счёт начисляют любую сумму, вне зависимости от того, есть ли у них такой нал, или нет. Ставка делается на то, что, в основном, люди обналичивают малую часть крупных сбережений, так что оверкоммит в банках используется абсолютно всегда, и именно этим раскручивается инфляция, а банкам - баснословные прибыли.

Да в некоторых случаях оверкоммит позволяет более
эффективно использовать физическую память, но в условиях
невозможности увеличения объема виртуальной, а в линуксе
размер свопа как правило фиксирован, это русская рулетка.

Как раз в случае невозможности увеличить виртуальную, это и нужно обязательно, иначе физическая память никогда не будет полностью занята, и вы станете получать ENOMEM гораздо раньше нормы. Это - _очень_ плохая ситуация.

Русская рулетка по умолчанию

Ну так делайте свап в 10 раз больше, чем оперативка, и отключайте оверкоммит. Только учтите одну деталь: отключение оверкоммита (echo 2 > overcommit_memory) ещё не даёт гарантий против OOM. Чтобы совсем исключить OOM, вы должны будете так же сделать и echo 0 > overcommit_ratio. Подумайте над этим фактом хорошенько.

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

Убрана поддержка процессоров серии 386

Ну всё, теперь линукс не нужен.

А что у кого-то есть комп с процессором младше Пентиума?

Freiheits-Sender ★★
()
Ответ на: комментарий от punya

а ты как хотел? что ты хочешь сказать?

кто все эти люди? какой мальчик?

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

Просто здесь это оффтопик, но я бы вам целую лекцию прочёл о том, как банки и на самом деле оверкоммитят.

А я как раз в курсе, и пример выбрал специально, что бы вы поняли к насколько большим карточным домикам такое поведение по умолчанию приводит в итоге, надеюсь последний финансовый коллапс на ипотечном рынке США, вылившийся в мировой кризис, помните ?

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

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

Это - _очень_ плохая ситуация.

Это очень плохая ситуация построена на приложениях от криворуких программистов, которых приучили к поведения системы по умолчанию выделять программам сколько угодно памяти = OVERCOMMIT_ALWAYS. cotap к примеру так и пишет

OVERCOMMIT_ALWAYS 1 — overcommit памяти есть всегда. Использовать лучше с совсем кривыми приложениями

Совсем, понимаешь, кривыми.

Хотя сам оверкоммит можно строить более изощренно, и таки отказывать в выделении памяти время от времени. Но ядростроителям видать тупо лень писать нормальную эвристику для оверкомита, зато куда интереснее бацать оную для ООМ.

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

Это очень плохая ситуация построена на приложениях от
криворуких программистов, которых приучили к поведения
системы по умолчанию выделять программам сколько угодно
памяти

Во первых, не только это. Что скажете про стек? Он тоже растёт динамически, соответственно, он изначально заоверкоммичен, так как в явном виде его вообще никто не выделял. Да и потом, что значит, «криворуких программистов»? Оверкоммит позволяет людям, вместо тысячи мелких маллоков, сделать один mmap(), и из него потом раздавать память по-немногу. Даже glibc имеет свой пул памяти, и на каждый free() не делает munmap(). Ничего криворукого тут нет - это отличный и полезный инструмент, позволяющий серьёзно сократить код и уменьшить кол-во системных вызовов. И в третьих, можете называть их криворукими, но свой код они уже написали, а вам - с этим жить. Так вот, оверкоммит и позволяет вам с этим жить вполне комфортно.

Хотя сам оверкоммит можно строить более изощренно, и таки
отказывать в выделении памяти время от времени. Но
ядростроителям видать тупо лень писать нормальную эвристику
для оверкомита, зато куда интереснее бацать оную для ООМ.

Ну здрасьте, а что, по вашему, означает 0 в overcommit_memory? Он и есть дефолтный, кстати.

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

Не пугайте меня так: я сам ипотечник и нищеброд.

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

Это очень плохая ситуация построена на приложениях от
криворуких программистов, которых приучили к поведения
системы по умолчанию выделять программам сколько угодно
памяти

Такая приученность, кстати, совершенно не подразумевает оверкоммит. Допустим, их приучили к этому большие свапы... Я вам уже говорил: свап в 10 раз больше оперативки, потом 2 в overcommit_memory и 0 в overcommit_ratio. Кто мешает то? Оверкоммит - для систем с малым свапом!

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

Размер блока - 2*размер структуры inode

Там ещё, вроде симлинки с xattrs-ами живут в иноде?

anonymous
()

Улучшена производительность сетевых драйверов, которые используются для паравиртуализации.

а то я думаю, чего патчить vmplayer пришлось то

actionless ★★★★★
()

Помоему Changelog содержит слишком много copy-paste из Changelog'ов веток 2.2, 2.4, 2.6

особенно на это намекает повторы с технологией Copy-On-Write, которой уже 100лет в обед, при работе с ОЗУ.

spigel
()
Ответ на: комментарий от post-factum

Радует слово «hopefully». Вот скомпилю, попробую.

Имею сказать, что с включёнными SNA и TearFree (cast ValdikSS) тиринга на Интеле теперь нет даже при перетаскивании окон между мониторами с различной частотой обновления. Аналогичного результата ранее можно было добиться только с одним видеодрайвером - fglrx. Теперь ждём такого же на nVidia.

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

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

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

Еще попробую запустить OpenGL через EGL, может, и это сработает.

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

Ну тогда прям не знаю. У меня даже на Intel HD 2000 с включённым TearFree разница между обычной версией и GLES очень и очень заметная, даже при том, что карта обслуживает два монитора. Правда, у меня Raring. Может вам ещё Месу обновить нужно, например? (Пальцем в небо.)

RussianNeuroMancer ★★★★★
()
Последнее исправление: RussianNeuroMancer (всего исправлений: 1)
Ответ на: комментарий от RussianNeuroMancer

Mesa 9.0.2. Разница, конечно, есть, но все-равно не плавно, а рывками. Ну ничего, в KDE 4.11 обещают патч уже включить, правда без гуишной настройки, но это мелочи.

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

Нет, GUI решили включить - см. обсуждение шестидневной давности на review board.

RussianNeuroMancer ★★★★★
()

post-factum, пользуясь случаем, хотел бы попросить рассмотреть возможность добавления RSS к Вашему сайту. Конкретно интересует RSS для мониторинга выхода новых версий pf-kernel.

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

Кроме RSS тебя больше ничего не устроит? Я там специально для определения версии в разных скриптах самообновляющийся файлик делал.

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