После 80 дней разработки увидел свет (http://lkml.org/lkml/2010/10/20/409) релиз Linux-ядра 2.6.36 (http://www.kernel.org) в котором появилась поддержка новой процессорной архитектуры Tile, интегрирована технология мандатного контроля доступа AppArmor, добавлена поддержка локального кэширования CIFS-разделов, обеспечена возможность управления питанием для CPU Intel Core i3/i5 и включена подсистема LIRC для управления устройствами через инфракрасный канал связи.
В новую версию принято 10195 исправлений от 1326 разработчиков,
размер патча - 48 Мб (добавлено 9256 тыс. строк кода, удалено -
9204 тыс. строк). Около 39% всех представленных в 2.6.36
изменений связаны с драйверами устройств, примерно 27% изменений имеют
отношение к обновлению кода специфичного для аппаратных архитектур, 12% связано с сетевым стеком, 6% - файловыми системами и 5% c внутренними подсистемами ядра.
В тексте анонса Линус Торвальдс отметил, что подготовка версии 2.6.36 немного затянулась, поэтому следую...URL: http://lkml.org/lkml/2010/10/20/409
Новость: http://www.opennet.me/opennews/art.shtml?num=28363
Про настройку OOKiller, где прочитать можно? А в предыдущих версиях ядра
пользователь мог задать процесс, который бы прибивался в случае нехватки памяти?
Сам спросил, сам отвечаю - http://lwn.net/Articles/391222/
Обещали Reiser4, где она?
кто и когда обещал? анонимус с ЛОРа?
Kjcjcyb neywf
http://www.opennet.me/opennews/art.shtml?num=24194
обстоятельства сложились не оптимистично :)
Уже надежды нет... Если не сейчас то никогда
Вот и у меня схожие предположения. Теперь, наверное, буду ждать декабря, тем глядишь ZFS допилят для GNU/Linux. Что бтрфс раньше закончат как то не надеюсь...
>Теперь, наверное, буду ждатьЯ тоже фшоке!! Они тормозят Прогресс!1! Ext2 может перестать работать просто с секунды на секунду, а они!.... Ужос+++
>декабря
И Санта-Клауса с новыми FS?
Как ты можешь ждать FS под несовместимой с GNU лицензией?
Кроме того - разве ZFS нужен для linux ?PS. а что кроме gnu/linux никто использовать ZFS не может ?:) что ты так категорично говоришь что пилят только для GNU/Linux.
> Как ты можешь ждать FS под несовместимой с GNU лицензией?Не стоит судить других по себе. Я не болен лицензионным фанатизмом, как ты мог подумать. У тебя если кто GNU GPL защищает, то ты его сразу в разряд использующих только GNU GPL записываешь. Ну или любую другую лицензию. Как кто то мне говорил, фанатики видят мир только чёрным и белым. Вот, это о тебе в данном случае.
> Кроме того - разве ZFS нужен для linux ?
Моё мнение - нужен.
> что ты так категорично говоришь что пилят только для GNU/Linux.
Так я о себе говорю, а не о пользователях FreeBSD или OpenIndiana, например.
Ну да :) нужен - что бы украсть - а потом зажимать исправления - они же под несовместимой лицензией?
Какие же вы предсказуемые.. Сначала вопль - а нафига она надо у нас вот BTRFS есть, а потом - ну давайте пилите быстрее мы тоже в linux kernel это хотим..
>Так я о себе говорю, а не о пользователях FreeBSD или OpenIndiana, например.А linux/busybox не пилят ?:)
> нужен - что бы украстьА как иначе? :)
P.S. Я же говорил, у вас всякий, кто от *BSD/BSDL-like кипятком не питает - GNU-фанбой и "неверный". Ну уж про "воровство" я вообще молчу.
> Сначала вопль - а нафига она надо
Вопили только дурачки и лицензионные фанатики, которые любую идею, втч идею свободного ПО способны довести до абсурда.
> А linux/busybox не пилят ?:)
Рискну предположить, что пилят для всех ОС на базе Linux.
>Рискну предположить, что пилят для всех ОС на базе Linux.А почему в оригинальном посте сужено до GNU/Linux ?
> А почему в оригинальном посте сужено до GNU/Linux ?Ну так потому что у меня GNU/Linux :), больше я ничего не имел ввиду.
А кто-нибудь знает, нулевой домен Xen всё ещё собираются включать?
Собираются. Они много патчей уже протащили. Ну и далее продолжат в 2.6.37
> Значительно переработан алгоритм OOM KillerНадеюсь, тебе не будет при нехватке памяти несколькоминутного iowait при отсутствии своп-раздела/файла? А то достало. Почему бы не пристрелить внезапно потёкший процесс без интенсивного шуршания блинами...
> Надеюсь, тебе не будет при нехватке памяти несколькоминутного iowait при отсутствии
> своп-раздела/файла? А то достало. Почему бы не пристрелить внезапно потёкший процесс без
> интенсивного шуршания блинами...Мне всегда было интересно - чем система так шуршит при отсутствии свапа ? причем настолько интенсивно, что остается только выключить железно. Кто нибудь, проясните ? Иногда протекает vlc.
исполняемые файлы в своп не скидываются, а тупо выгружаются из памяти. При прибитии процесса ядру хочется почитать, что там было (мало ли есть какой признак, что процесс не может быть прибит, тогда надо искать другой процесс), он начинает загружать исполняемое файло в память, но памяти нет, надо выгрузить исполняемый файл другого процесса, а он тоже хочет работать, да и не только он, есть еще куча других процессов, отжирающих ресурсы.
Да еще учесть, что рабочих процессов в системе где-то 100-200, каждый раз выкидывая кого-нить, а потом подгружая его и сопутствующие библиотеки, тратится время на io-seek.
Спасибо, мистика доходчиво разъяснена. С другой стороны, получается, что наличие свопа в данной ситуации сильно улучшит дело, потому что тупо считать длинный блок данных из свопа проще чем пытаться загрузить какой нибудь бинарник ? А в ядре ничего нельзя подкрутить, чтобы подобного непотребства не было ?
своп в одном месте лежит, а бинарники размазаны по всем разделам
>исполняемые файлы в своп не скидываются, а тупо выгружаются из памяти.Если не ошибаюсь то в своп не выгружает код тольок винда, линукс как раз все может выгружать.
А шушршать винтом при простое может драйвер ExtFS(мало ли что он там делает), возможно кеши дисковые скидываться из ОП итд
>>исполняемые файлы в своп не скидываются, а тупо выгружаются из памяти.
> Если не ошибаюсь то в своп не выгружает код тольок винда, линукс
> как раз все может выгружать.A lot of the contents of an executable image come from the image's file and can easily be re-read from that file. For example, the executable instructions of an image will never be modified by the image and so will never be written to the swap file. These pages can simply be discarded; when they are again referenced by the process, they will be brought back into memory from the executable image.
http://tldp.org/LDP/tlk/mm/memory.html
>>>исполняемые файлы в своп не скидываются, а тупо выгружаются из памяти.
>> Если не ошибаюсь то в своп не выгружает код тольок винда, линукс
>> как раз все может выгружать.у венды такой штукенции как раз нет, т.к. там нет inode
>>>>исполняемые файлы в своп не скидываются, а тупо выгружаются из памяти.
>>> Если не ошибаюсь то в своп не выгружает код тольок винда, линукс как раз все может выгружать.
> у венды такой штукенции как раз нет, т.к. там нет inodehttp://wall.riscom.net/books/win/petzbook/PART3_7.TXT
Chapter 7 Memory Management
Discardable Memory
When Windows discards a code
segment, it can later reload the code segment by accessing the .EXE file.
Most of Windows' own code in the USER and GDI modules and various driver
libraries is also discardable. (The KERNEL module is fixed. This is the
module responsible for Windows' memory management.) Resources--such as
dialog box templates, cursors, and icons--also are often marked as
discardable. Again, Windows can simply reload the resource into memory by
accessing the .EXE file that contains the resource.
> у венды такой штукенции как раз нет, т.к. там нет inodeОна просто не даёт изменять имя замапленного файла :) поэтому ей не нужен inode. И, кстати, на NTFS что-то подобное inode есть, так как на NTFS можно переименовывать зампленый файл.
Можно как-то отключить такое поведение?
идексатор бигля, который на моно.
iotop запусти и узнай.
сбрасывает закешированное?
> Мне всегда было интересно - чем система так шуршит при отсутствии свапа ?Зачастую lsof дает пищу для размышлений. Как правило это оказывается какая-нибудь индексилка работающая по крону или типа того.
gfrhrf>Иногда протекает vlc.можно сделать скрипт-обертку с принудитльным ограничением памяти
ulimit -m 200000 # -c unlimited
exec vlc ~/radioТогда при превышении квоты прочесс будет автоматом уничтожен.
>> Надеюсь, тебе не будет при нехватке памяти несколькоминутного iowait при отсутствии
>> своп-раздела/файла? А то достало. Почему бы не пристрелить внезапно потёкший процесс без
>> интенсивного шуршания блинами...
> Мне всегда было интересно - чем система так шуршит при отсутствии свапа
> ? причем настолько интенсивно, что остается только выключить железно. Кто нибудь,
> проясните ? Иногда протекает vlc.видимо все авторы этой ветки выше забыли прочесть вопрос
ПРИ НЕХВАТКЕ ПАМЯТИ (осталось 150 метров из 2х гигов допустим) НАЧИНАЕТСЯ ДИЧАЙШИЙ ЮСЕДЖ ВИНТА НА МНОГО МИНУТ (при том что СВОП ФИЗИЧЕСКИ НЕ СУЩЕСТВУЕТ НА КОМПЕ)
делать что либо нереально, омкилер не стартует в это время, если какая то задача отрабатывает и освобождает память то всё приходит в норм
собсно вопрос - что происходит ?
линукс поочерёдно трёт из памяти программы (исполняемый код, но не данные) (дабы освободить места в памяти) а после обратно считывает их с файловых образов когда приходит им время урвать свой кусочек процессора ? можно както влиять на ситуацию ? а то сидишь минут 15 и думаешь пришибутся иксы, всё обойдётся или "надо было ещё 15 минут назад жать резет"
А btrfs заглохла или уже допилили, или почему про это ничего нет?
> А btrfs заглохла или уже допилили, или почему про это ничего нет?до 12.04 еще времени куча, думаю, что успеют допилить. в 2.6.36 ничего не выкатили существенного. мелкие багфиксы тоже решили не выкладывать, все равно будет скоро очередной апгрейд с ломанием совместимости с текущей версией btrfs.
>все равно будет скоро очередной апгрейд с ломанием совместимости с текущей версией btrfs.откель инфа?
А что будет 12.04? Или это релиз убунты?
конец света?
Если бы допилили, то написали бы. В rc всё ещё была пометка "Unstable disk format", как в релизе не знаю, но думаю, так же.
да вроде уже допилили
можно в прадкшен? API и формат больше менять не будут?
что такое "Нажатие Sysrq-g "
а по делу-где zfs!?
> что такое "Нажатие Sysrq-g "[Alt] + [Print Screen] (а.к.а. [SysRq])
> а по делу-где zfs!?
Там же, где reiser4
"В файловой системе Ext3 теперь по умолчанию используется режим упорядоченного журналирования (mount -o data=ordered), при котором вначале на диск сбрасываются обновления данных, а потом в журнал помещаются изменения метаданных, что гарантирует отсутствие в файлах устаревших блоков данных в случае краха;"Не понял, а раньше тогда как было?
было -o data=writeback по дефолту, если в суперблоке не указано иное.
Ничто так не поднимает настроение, как changelog очередного релиза ядра =)
А где reiser4 ? (((
в ...изде!
Накой он тебе нужен?
> в ...изде!
> Накой он тебе нужен?reiser4 действительно нужен. А вот накой Netfilter рассовывать по ядрам?
>> в ...изде!
>> Накой он тебе нужен?
> reiser4 действительно нужен. А вот накой Netfilter рассовывать по ядрам?Ну вот представь, ты 32 портовый, 10Gb коммутатор/маршрутизатор,
сколькими головами лучше считать фильтрацию, одной или 32-мя? :)
>>> в ...изде!
>>> Накой он тебе нужен?
>> reiser4 действительно нужен. А вот накой Netfilter рассовывать по ядрам?
> Ну вот представь, ты 32 портовый, 10Gb коммутатор/маршрутизатор,"Оно" скорее не про масштабирование на много процессоров, а про кэш-локалити, чтоб наоборот по _разным не скакало... IMHO, мне так почему-то показалось.
> сколькими головами лучше считать фильтрацию, одной или 32-мя? :)
Лучше 1 раз по разу, чем ни разу трид-цать два. :D
Наконец-то lirc запихнули!
/me представил себе будущее... на 64-ядерном проце айпитаблес легко гоняет пачку правил, да еще и рассовав их по ядрам. Ну разве не красота? :)ЗЫЖ кто там 48-ядерные процы хотел? Ну вот и посмотрим как там с масштабированием. Ставлю на то что проблемы с масштабированием решат, если они вылезут и начнут мешаться.
> /me представил себе будущее... на 64-ядерном проце айпитаблес легко гоняет пачку правил,
> да еще и рассовав их по ядрам. Ну разве не красота?
> :)для этого надо сначала разделить спинлок защищающий правила - а то он там 1 штука, и от того что один из модулей будет закинут на произвольный CPU - легче никому не станет. разбиение на rwlock будет просто вызывать кучу cache flush - что не лучшим образом сказывается на производительности.
Кроме того расскидывание по процам добавляет гемороя с обработкой пакетов ибо далеко не каждый протокол безболезнено переживает переупорядочивание пакетов.
Допустим для tcp это означает уменьшение производительности, отключение sack, и увеличение используемой памяти на клиенте.
> ЗЫЖ кто там 48-ядерные процы хотел? Ну вот и посмотрим как там
> с масштабированием. Ставлю на то что проблемы с масштабированием решат, если
> они вылезут и начнут мешаться.Там где используют много ядер - там iptables не используют. он там отключен как класс.
PS. прежде чем говорить - стоило бы подумать.
>[оверквотинг удален]
>> :)
> для этого надо сначала разделить спинлок защищающий правила - а то он
> там 1 штука, и от того что один из модулей будет
> закинут на произвольный CPU - легче никому не станет. разбиение на
> rwlock будет просто вызывать кучу cache flush - что не лучшим
> образом сказывается на производительности.
> Кроме того расскидывание по процам добавляет гемороя с обработкой пакетов ибо далеко
> не каждый протокол безболезнено переживает переупорядочивание пакетов.
> Допустим для tcp это означает уменьшение производительности, отключение sack, и увеличение
> используемой памяти на клиенте.А кто те сказал, что оно будет рубить одну сессию на части?
>Там где используют много ядер - там iptables не используют. он там отключен как класс.Мда, а нахрен тогда такие http://www.tilera.com/products/processors/TILE64 системы делают?
А потом поддержку этих систем в ядро встраивают "Поддержка процессорной архитектуры Tile, отличающейся возможностью интеграции на одном чипе до нескольких сотен процессорных ядер."
Т.е. можешь взять платформу http://www.tilera.com/products/platforms и настроить железяку как рутер/файервол...
Или купить готовое решение http://www.napatech.com/applications/applications.html на той же по сути платформе ...
При внутренних скоростях проца 31 Tbps of on-chip mesh interconnect можно каждое правило на свое ядро повесить и будет пофиг откуда/куда и сколько раз пакет по процу пролетел и в какой последовательности (преувеличение конечно небольшое :) ).
Заметил странное в ChangeLog-2.6.36
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.36Некоторые коммиты имеют дату вида:
commit f5e70d0fe3ea990cfb3fc8d7f76a719adcb1e0b5
Author: David Woodhouse <dwmw2@tylersburg.infradead.org>
Date: Mon Jul 13 11:35:12 2009 +0100(в самом низу лога)
Это действительно из 2009 года или они пользуются машиной времени?
Я предполагаю что в ChangeLog для 2.6.36 должны быть комиты не позднее выхода 2.6.35.
Объясните, пожалуйста, почему так происходит.
История коммитов нелинейная. Возможно, после 35 мержнули какую-нибудь старую ветку.
а вот по поводу LIRC это видимо связано с тем что Гугле.ТиВи активно начали продавать...
> В NetFilter добавлена возможность привязки правила к CPUИйессссс!!!
>>Ийессссс!!тебе так сильно этого хотелось?
Как там с ath9k_htc? В 2.6.35 были проблемы, дикие пинги.