Объявлено (http://lkml.org/lkml/2007/10/9/241) о выходе нового релиза Linux ядра - 2.6.23. Ниже обзор наиболее ярких новшеств (http://kernelnewbies.org/Linux_2_6_23):- Приняты патчи с реализацией мониторов виртуальных машин (гипервизоров) lguest ( крайне простая в управлении система паравиртуализации , позволяющая запустить Linux ядро как пользовательский процесс) и Xen . Кроме того в гипервизоре KVM реализована поддержка эмуляции многопроцессорных систем (SMP guest);
- Для выделения памяти для кеширования объектов ядра по умолчанию используется SLUB allocator (http://lwn.net/Articles/229984) (оптимизирован для SMP систем);
- Планировщик задач с полностью справедливым распределением ресурсов CFS (Completely Fair Scheduler);
- Новый, переработанный, базовый драйвер для SCSI устройств;
- UIO (user-space IO) - позволяет создавать драйверы для работы с устройствами ввода/вывода работающие как пользовательские процессы.
- Увеличение производительности чтения файлов, через реализацию упреждающиего чтения блоков (On-demand read-ahead). Позволило увеличить производительность MySQL в sysbench/OLTP тестах на 8%;- Реализация PPP поверх L2TP (http://www.ietf.org/rfc/rfc2661.txt), например проброс PPP поверх UDP туннеля;
- Новый системный вызов fallocate() (http://lwn.net/Articles/240571/), для гарантированного резервирования места в ФС под файл;
- Для устранения лишних пересылок между буферами ядра, в sendfile() задействовали новый механизм ввода/вывода - splice, появившийся в ядре 2.6.17;- Снятие ограничения на размер параметров в командной строке процесса, место теперь выделяется динамически, максимальный лимит устанавливается в 25% от лимита на размер стека (ulimit -s). Ошибка "argument list too long" ушла в прошлое.
- Улучшение файловых систем XFS (Lazy Superblock Counters, Concurrent Multi-File Data Streams) и ext4 (устранен лимит на 65000 вложенных директорий, переход на учет наносукунд, ;
- Поддержка сетевых устройств с возможностью организации нескольких очередей пакетов;- Реализация флага O_CLOEXEC (http://lwn.net/Articles/232575/) ("close-on-exec") для файловых дескрипторов, для устранения возможности перехвата файлового дескриптора в приложении, запущенном из многопоточной программы, изначально использующей этот дескриптор;
URL: http://lkml.org/lkml/2007/10/9/241
Новость: http://www.opennet.me/opennews/art.shtml?num=12378
С каждым новым релизом, Linux все больше становиться Linux'ом
Бльше новых API разных и разнообразных!
>UIO (user-space IO) - позволяет создавать драйверы для работы с устройствами ввода/вывода работающие как пользовательские процессы.Наконец-то выньмопеды (кудаж от них денешься на ноутах) с их проприетарным кодом начнут работать в юзерспейсе.
собрал 23е, к debian etch
пока все нравится =)
Сэр, вы наверно не видели /proc/interrupts !!! :) (Для SMP_шников (multicore), остальным не актуально).
>В материале "Linux 2.6.23 Kernel Benchmarks" проведено сравнение
>производительности (кодирование звука, quake, сжатие данных) Linux ядер 2.6.23
>и 2.6.22.9, производительность, с учетом погрешности, оказалась на одном уровне.А что, ожидалось что ядро сможет быстрее жать данные или звук ?? Смешно.
>Для устранения лишних пересылок между буферами ядра, в sendfile()
>задействовали новый механизм ввода/вывода - splice, появившийся в ядре 2.6.17;Вот что влияет на производительность _ядра_...
вовоа кроме того, 2.6.23 все-таки быстрее .22-го.
Пусть кому-то это кажеться и в пределах погрешности, но все ж в обратнуюу сторону почему-то "ошибок" нет ;)))смотрим счетчики в тестах и видим, что .23 все-таки быстрее.
>Пусть кому-то это кажеться и в пределах погрешности, но все ж в
>обратнуюу сторону почему-то "ошибок" нет ;)))
>смотрим счетчики в тестах и видим, что .23 все-таки быстрее.Потому что стало шустрее но в этих тестах бОльшую часть CPU жрет userspace и на фоне этого выигрыш в кернеле оказывается "в пределах погрешности".Методика тестирования хреновая, подсистемы ЯДРА мало прогружены.
>Новый, переработанный, базовый драйвер для SCSI устройств;Вроде в 2.6.20 уже было включение некоей переработки ? Еще одна ?
"UIO (user-space IO) - позволяет создавать драйверы для работы с устройствами ввода/вывода работающие как пользовательские процессы."Перевожу: "сопротивление бесполезно, эволюция хоть и окольными путями, но ведёт к микроядру".
Следующим будет "виртуализация как стандартное средство изоляции прикладных процессов от ОС для обеспечения безопасности, отказоустойчивости и управления распределением вычислительных ресурсов". Лет через 10 до всех дойдёт.
>"UIO (user-space IO) - позволяет создавать драйверы для работы с устройствами ввода/вывода
>работающие как пользовательские процессы."
>
>Перевожу: "сопротивление бесполезно, эволюция хоть и окольными путями, но ведёт к микроядру".хэх... по живому режешь...
>Следующим будет "виртуализация как стандартное средство изоляции прикладных процессов от ОС для
>обеспечения безопасности, отказоустойчивости и управления распределением вычислительных ресурсов". Лет через 10
>до всех дойдёт.да уже и счас дошло до многих... но переделывать мягко говоря ОЧЕНЬ много...
о
да это ж ты, Белкин :)
Линукс сейчас не в топке только потому, что быстрый. Если его сделают микроядерным, он станет супертормозом похуже openbsd. И чем это по-вашему закончится?
>Линукс сейчас не в топке только потому, что быстрый. Если его сделают
>микроядерным, он станет супертормозом похуже openbsd. И чем это по-вашему закончится?и будет такая _ветка_ Линукса (потому как основная, монолитная, ессьно продолжит свое такое же стремительное развитие) побезопасней всяких OpenBSD ;)
вот тогда мы вас, товарисч, послушаем...кому нужна будет скорость - возьмет монолит ветку. Кому паранойя спать мешает - микро версию.
Ненаучная фантастика какая-то.... Сейчас вон патч с -mm до ванилы 30 метров весит и Мортон стонет, что оно уже не собирается толком, а уж микроядро патчем сделать... Давайте ещё третью версию сделаем, как у мелкософта - чтобы наоборот максимум в ядро утащить! Делов то... Nick на выходных напишет.... :-)
>Ненаучная фантастика какая-то.... Сейчас вон патч с -mm до ванилы 30 метров
>весит и Мортон стонет, что оно уже не собирается толком, а
>уж микроядро патчем сделать... Давайте ещё третью версию сделаем, как у
>мелкософта - чтобы наоборот максимум в ядро утащить! Делов то... Nick
>на выходных напишет.... :-)гы :)
Nick то напишет... шо-то...
но стока не курят ни Мортон, ни Торвальдс...
Неважно какой был бы дифф поразмеру с монолита на мегалит %)))
Он развивалсо бы с момента разделения самостоятельно, лишь портируя пачти
из монолита в соответстсвующие сервиса микроядра.Тут, как грицо, главное начать
Читайте Таденбаума. Переход на микроядерную архитектуру сжирает 2-4% процессорного времени и не более. Так что говорить про тормоза особо не уместно.
>>Читайте Таденбаума. Переход на микроядерную архитектуру сжирает 2-4% процессорного времени и не более. Так что говорить про тормоза особо не уместно.читайте-читайте. В теории много чего хорошего пишут. Только вот на практике что-то не получается.
А что с QNX не так?
http://cmp.nm.ru/reiser4-for-2.6.23.cmp.patch.bz2
А как включить этот CFS-планировщик? Среди доступных его нет, что и где включить, чтобы он появился?
>А как включить этот CFS-планировщик? Среди доступных его нет, что и где
>включить, чтобы он появился?видимо, ты перепутал шедулер проца и ввода/вывода.
Только шедулеры в/в включаются на выбор.
Шедулер проца же один и не переключаеться при конфигурации.
Просто с .22 версии до .23 его заменили с O(1) на CFS.Перед Торвальдсом стоял вопрос о включении альтернативного выбора плнировщика при сборке.
Даже патч был. Но он это все послал лесом, ибо нефиг включать в ядро менее качественный шедулер. Тяжело не согласиццо :)
Запутался немного :-). Теперь всё ясно, спасибо.