LINUX.ORG.RU

Новая версия ОС MINIX3

 


0

0

Вышла новая версия ОС MINIX 3.1.4 релиз 4203. Среди нововведений следует отметить появление поддержки виртуальной памяти. Список программного обеспечения под MINIX 3 и сам дистрибутив можно скачать с официального сайта MINIX 3.

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

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

>> Ну почему же, вдруг встречу доброго человека, который просветит ламера.

> Как в компиляторах? :)

И не только в компиляторах %)

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

> Если систему - да.

Ради этого случая всё и делается. Хотя приятным побочным эффектом будет облегчение оазработки драйверов :)

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

А че жеманишься, девочка?

Ставь уж и на работу вендовс XP хом эдишен.

Нельзя быть чуть-чуть беременной...

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

>> Вызов open приводит в MINIX к 4-6 и более переключений контекстов. Т.е. кеши кода, данных, TLB хреновенько используются. Ситуация, когда каждая задача на своем ядре (даже если ядер много) маловероятна, т.к. ядра одинаковые, а ресурсы CPU кушают по разному

>Ыыыы, какая каша. Единственное, о чем здесь стоит беспокоиться, это нерациональное исользование кэшей процессора. Но рост производительности процессоров делает эти накладные расходы относительно менее важными. Вообще, закон Мура работает на Minix3.

Ыыыы, все с точностью до наоборот. Рост производительности процессора делает его работу с кэшем все более важной, иначе нахрена ему кэш? Оптимизация работы с кэшем, банальное выравнивание адресов и группировка данных по длинне строки может дать прирост в производительности до пяти раз. Именно нехватка кэша была в свое время боттлнеком гипертрединга.

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

> Рост производительности процессора делает его работу с кэшем все более важной, иначе нахрена ему кэш? Оптимизация работы с кэшем, банальное выравнивание адресов и группировка данных по длинне строки может дать прирост в производительности до пяти раз.

Спасибо, К.О. Ты посмотри, о чем речь шла.

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

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

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

> сама реализация возможности перезапуска железа, как и драйвера реально привносит еще больше ошибок и зависов

Перезапуск драйвера в Minix3 - это перезапуск процесса, какие там баги?

> за счет усложнения кода и неизлечимых багах в самой процедуре хотплага

Это ни на грамм не хуже сравнению с монолитным ядром.

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

>> ... намертво привинченная к x86/32 бита, ага

> У них в планах портирование на ARM и PowerPC.

У меня тоже много чего в планах. Who cares? Студенты разглядывали намедни код ядра и писали по нему отчёты, и когда они не копипастили самого Таненбаума -- получалось довольно увлекательно, там постоянно своеобразные решения, начиная с отсутствия страничной адресации (ну это, видимо, пофиксено).

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

> Who cares?

Это как бы намек на то, что привинчено оно не намертво.

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

> Линукс же опирается на систему бесконечных патчей
убей себя об стенку! Солярис точно также опирается на "систему бесконечных патчей" (см. man patchadd) - и что - от этого он стал хуже?
И никто не может сказать что Солярис недостаточно надёжен.

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

>> Рост производительности процессора делает его работу с кэшем все более важной, иначе нахрена ему кэш? Оптимизация работы с кэшем, банальное выравнивание адресов и группировка данных по длинне строки может дать прирост в производительности до пяти раз.

>Спасибо, К.О. Ты посмотри, о чем речь шла.

А речь шла вот об этом:

> Вызов open приводит в MINIX к 4-6 и более переключений контекстов. Т.е. кеши кода, данных, TLB хреновенько используются. Ситуация, когда каждая задача на своем ядре (даже если ядер много) маловероятна, т.к. ядра одинаковые, а ресурсы CPU кушают по разному

Собственно я с товарищем и согласился, а с ростом производительности процессоров ситуация будет только усугубляться.

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

>> ... намертво привинченная к x86/32 бита, ага

> У них в планах портирование на ARM и PowerPC.

Что говорит о том, что производительность в будущем упадет еще разок.

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

>> Вызов open приводит в MINIX к 4-6 и более переключений контекстов. Т.е. кеши кода, данных, TLB хреновенько используются. Ситуация, когда каждая задача на своем ядре (даже если ядер много) маловероятна, т.к. ядра одинаковые, а ресурсы CPU кушают по разному

> Собственно я с товарищем и согласился, а с ростом производительности процессоров ситуация будет только усугубляться.

А вот для этого и нужны цифры. Я лично считаю, что с ростом производительности процессоров накладные расходы на всякие переключения всё менее важны. Кстати, за кэши беспокоиться не надо - переключение контекстов не затрагивает L2 и L3-кэши, а L1-невелик и заполняется быстро.

И даже сброс TLB со временем станет всё менее вредным - man tagged TLB.

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

Сомневаюсь, что кот-то будет читать но ответить все же стоит :)

>Я лично считаю, что с ростом производительности процессоров накладные расходы на всякие переключения всё менее важны.

С ростом производительности процессоров сначала появились L1, потом L2, а уж потом L3 кэши. Если так пойдет и дальше, то с будут появляться кэши Ln+1. Зачем нам такое многообразие, ведь наличие многоуровневого кэша только удорожает проектирование процессора? Правильно, потому что каждый новый уровень кэша делает ошибки выборки менее заметными, примерно в два раза. И нужно это что бы потребитель ощущал стабильный прирост производительности от наращивания количества памяти и тактовой частоты процессора. Спасением стало то, что сейчас на массовый рынок стали выходить 4-х процессорные системы. Именно наращивание количества процессоров может нивелировать плохую работу с кэшем, но только в случае если задачи не будут "гулять" между ядрами, иначе может дойти до того, что увеличение количества процессоров будет уменьшать производительность.

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

> Сомневаюсь, что кот-то будет читать

Напрасно.

> Именно наращивание количества процессоров может нивелировать плохую работу с кэшем, но только в случае если задачи не будут "гулять" между ядрами

Спасибо, К.О. Но причем здесь Minix3? Это общие проблемы всех ОС, микроядерных или нет.

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

>> Именно наращивание количества процессоров может нивелировать плохую работу с кэшем,...

>Но причем здесь Minix3? Это общие проблемы всех ОС, микроядерных или нет.

При том, что основной тезис был, если вы припомните конечно, что микроядро неэффективно использует кэш из-за роста переключений контекста. Вы сказали, что это не беда раз производительность процессоров растет. Я на это возразил, что это как раз становится бедой с ростом производительности. Вы назвали меня в ответ на это КО, что мне несомненно льстит как призание бесспорности моих возражений. А раз и на дальнейшие возражения вы изволите называть меня КО, может опустим формальности и будем называть меня просто - Гуру :))) Исключительно шутка.

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

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

На что был ответ - при переключении контекстов теряется лишь L1, L2 и дальше остаются нетронутыми. L1 невелик и заполняется быстро благодаря повышению скорости процессоров и кэшей. Методы оптимизации сброса TLB тоже постепенно появляются в мэйнстримных процах. Из-за того, что размер TLB не растет, сброс TLB - это фиксированный оверхэд. Итого, переключение контекста - это сумма небольшого оверхэда с фиксированным. Это значит, что при повышении быстродействия эти потери состваляеют все меньший процент производительности. Поэтому невыгодные вчера микроядра становятся приемлемо эффективными.

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

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

> Студенты разглядывали намедни код ядра и писали по нему отчёты, и когда они не копипастили самого Таненбаума -- получалось довольно увлекательно,

Можно запостить наиболее интересные куски?

www_linux_org_ru ★★★★★
()

Тенненбаум&Co реально жжет. но "один в поле не воин" и задачи себе они поставили - безрамерные, для такой комманды. с другой стороны - без Challenge, как Творить ?

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

Во первых - микроядерная система не обязательно тормознутая. Это миникс тормознутый. А сейчас с разными адресными пространствами тормозов наверное поприбавилось. Во вторых Линус помнится добавил поддержку свапа в ядро дня за три. (just for fun) В третьих они видимо поэтому так долго возились потому что у их изначально все в одном адресс спейс

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

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

Т.е. микроядро на "завтрашних" процессорах "приемлемо эффективно" СЕГОДНЯ?:)

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