Тестирование аллокатора памяти FreeBSD

>Когда IOMMU будут на каждом компе - тогда может быть.
вполне возможно уже скоро- ведь без него DRM работать не будет...

alex-w> Quasar, вот не брался бы ты судить о том, в чем не разбираешься, а...

FreeBSD скорее враг чем друг.

>и linux, и bsd нужна здоровая конкуренция, иначе они оба загнутся...

без жигулей мерседес загнеться !

>FreeBSD скорее враг чем друг.

Это вам в ГНУ так мозг промыли?

>Это вам в ГНУ так мозг промыли?

http://www.gnu.org/licenses/license-list.ru.html

Нет там такого. Никакого промывания.

>FreeBSD скорее враг чем друг.
>Quasar

Пришел однажды Quasar с работы - замученный, голодный и злой а там ... фрибсд-шники его жену попчутЪ ... Неее - Фреебзд квазару враг!

Жаль НИКТО не прокомментировал мои 10%.

*** ВОПРОС КО ВСЕМ ***

сколько процентов цпу вы согласны отдать за "обращение к порту или массив обращений к порту -- это сисколл" ?

>> Какие проблемы он отрицает (список плиз)

>Все :) Если серьезно, я не читал ничего по Minix3 уже с год, так что не могу дать подробный Minix3-специфичный отчет.

Не обязетльно отчет... но ссылочки хотя бы на выразителей твоего мнения.

> Поправьте меня кто-нить, если я ошибаюсь, но в Minix3 _нет_ DMA 8)

Я тут тоже малограмотный :-(

> Скажу как ветеран драйверопейсания - драйвер может завесить систему даже через системные вызовы обращения к портам

Верю, даже не написав ни одного драйвера :-) Но гораздо лучше, чтобы глючные драйвера чего-то-там хотя бы не могли залезть в порты диска. И за это я готов платить 10% цпу.

> К везению это не имеет отношения - эторезультат работы. Так что это не прекратится внезапно.

Я это подозревал :-)

> глючащий драйвер диска сделает систему неюзабельной

Кто увелкается левыми драйверами рейд контроллеров -- сам себе злобный буратино. И это никакими миниксами не вылечить.

Эээ... я чуть ли не готов поступиться принципами и запихнуть драйвер IDE ядро... но это была минутная слабость :-)

Но за счет миникса можно добиться того, чтобы глючная драйверосвистелка НЕ ЛЕЗЛА В IDE ПОРТЫ!

>> кому нужно много, есть SYS_VDEVIO -- process vectior with multiple (port IO) requests -- пусть объединяют реквесты,

> Не уверен, что это нормальный выход.

Почему??? (на пальцах можно объяснить?)

>> все равно в реальной жизни больше 1000 сисколлов в секунду не нужно

> "640К хватит для всех" (c)

А вот это явно __некорректный__ способ вести дискуссию.

Я объяснил почему хватит. Надо указать на мои ошибки.

Поясню: на видеокарту, диск, сетевуху в монолитном ядре может и должно сыпаться намного больше реквестов. Но в микроядре эти реквесты должны объединяться драйверами и выливаться в намного меньше чем 1000/сек число сисколлов, каждый из которых имеет право быть вектором из 10 000 реквестов. Так что никакого лимита тут НЕТ. Надо тебе больше 10М реквестов в секунду -- ПОЖАЛУСТА! -- но объединяй их в вектора!!!

>то что я хотел сказать - я сказал. Это касается любого подобного теста - сразу видно откуда ноги растут и чего автор добивается ;)

Тогда чего вы удивляетесь, когда пользователи других операционок видят аналогичные тесты, проводимые IBM, Novell, Red Hat и др. linux-компаниями и расценивают их аналогично - высосаный из пальца get the facts от linux?

>FreeBSD скорее враг чем друг.

Тогда тем более нехрен обсирать то, что не видел.

>Это вам в ГНУ так мозг промыли?

Да это скорее промывка местного разлива :-/

>> все равно в реальной жизни больше 1000 сисколлов в секунду не нужно

> "640К хватит для всех" (c)

Сискол != реквест

Сискол = 1000 * реквест

SYS_VDEVIO -- process vectior with multiple (port IO) requests

> скорость (ибо обращения к системным службам стоят дорого из-за переключения контекстов и передачи сообщений)

Вот ты опытный драйверописатель -- так предложи тест, похожий на реальность, в котором бы эти тормоза выглядели ярко??? Хотя бы идею подай, да и прога я думаю в 300 строк вполне уложится...

> Именно. Только почему они не написали, с какой либой линковали под фрей? -lthr или -pthread?

Потому, что это про FreeBSD 7 и 8. A там libpthread -- это symlink на libthr.

скажу больше, сегодня в HEAD удалили libkse

Тоже симлинк сделали? :D

В ветке 7.x, например, SCHED_SMP переименовали в SCHED_ULE. Ну это надо же! Никто и не догадается, что старый SCHED_ULE заброшен в сентябре 2005 году и остался только в ветке 6.x. :))

>Дизайн аллокатора фиг один сопрут. вопрос времени.

kqueue/netgraph/etc который год уже прут?

> старый SCHED_ULE заброшен в сентябре 2005 году "старый" SCHED_ULE по правде никогда и не был работоспособным его код был сильно переписан в то, чем оно стало в 7.x > SCHED_SMP переименовали в SCHED_ULE SCHED_SMP - это просто другое (рабочее) название уже переписанного планировщика, отличительной особенностью которого стала скалируемость на SMP. Сейчас это название уже не употребляется

[форматирование]

> старый SCHED_ULE заброшен в сентябре 2005 году

"старый" SCHED_ULE по правде никогда и не был работоспособным его код был сильно переписан в то, чем оно стало в 7.x

> SCHED_SMP переименовали в SCHED_ULE

SCHED_SMP - это просто другое (рабочее) название уже переписанного планировщика, отличительной особенностью которого стала скалируемость на SMP. Сейчас это название уже не употребляется

>nikolayd> Только почему они не написали, с какой либой линковали под фрей? -lthr или -pthread?

>Потому, что по честному они не могут. Если по честному будет, линукс порвёт фрю.

Линуксоиды, меряються знаниями FreeBSD. Бугога.

PS: ЧистА для справки - в FreeBSD7 и выше libpthread симлинк на libthr

> Так называемая "страничная виртуальная память" нужна для эффективного свопа данных из оперативной памяти на медленное устройство хранения (жёстий диск) и обратно.

Ну что тебе сказать, кроме "бугага"? Виртуальная память - это не совсем подкачка aka paging. Если ты не знал: в Minix3 система управления виртуальной памятью _сегментная_. Последствия объяснять надо?

> Оперативная память подешевела, её объёмы на десктопах исчисляются парой гигабайт, свопирование практически не исользуется

Подкачку изобрели 50 лет назад. Если ты думаешь, что сейчас она вдруг выйдет из моды... программы всегда расширялись так, чтобы заполнить всю доступную памятьть (== да вы же, жабакодеры, этого не допустите).

>Линуксоиды, меряються знаниями FreeBSD. Бугога.

+1

> netgraph

А вот этой вкусняшки в лупиксе никогда не будет :)

Ты б тред для начала прочитал - еще на первой странице обсудили -_-

>>> кому нужно много, есть SYS_VDEVIO -- process vectior with multiple (port IO) requests -- пусть объединяют реквесты,

>> Не уверен, что это нормальный выход.

>Почему??? (на пальцах можно объяснить?)

Потому что последовательность "прочитать порт; проанализировать значение; в зависимости от результата прочитать еще один или другой порт" векторизации не поддается.

>>> все равно в реальной жизни больше 1000 сисколлов в секунду не нужно

>> "640К хватит для всех" (c)

>А вот это явно __некорректный__ способ вести дискуссию.

А по-моему, нормально. Ты не обосновал свою цифру.

> на видеокарту, диск, сетевуху в монолитном ядре может и должно сыпаться намного больше реквестов. Но в микроядре эти реквесты должны объединяться драйверами и выливаться в намного меньше чем 1000/сек число сисколлов, каждый из которых имеет право быть вектором из 10 000 реквестов. Так что никакого лимита тут НЕТ.

Ы? Речь шла о том, что запрос на чтение порта работает через сисколл, это не запросы к драйверу, а запросы из самого драйвера. Никакое объединение запросов здесь не сработает.

> Надо тебе больше 10М реквестов в секунду -- ПОЖАЛУСТА! -- но объединяй их в вектора!!!

Ыыыы... Допустим, VM нужно прочитать с диска страницу (одну), а слою TCP - принять пакет (один) - как это векторизовать? Ну и не думай, что традиционные системы не делают векторизацию - делают, где возможно (но это отнюдь не драйверы устройств - хотя в микроядерной ОС, возможно, это отдадут в драйвер).

> предложи тест, похожий на реальность, в котором бы эти тормоза выглядели ярко???

"There are lies, damned lies and benchmarking results" (c)

> Хотя бы идею подай, да и прога я думаю в 300 строк вполне уложится...

Не уложится. Ближайший к реальности тест, который я могу придумать - взять простой драйвер GigE, близкий по исходникам между Minix3 и Линукс, и проверить его на передачу UDP-трафика _без_ использования jumbo frames - смотреть не только на скорость (она может быть одинаковой), но и на потребление ресурсов ЦП (и кэша неплохо бы).

Ай-ай-ай, врать не хорошо. Посмотри например какие ОС поддерживает *nix версия Flex Builder'а.

*хором* к логопеду, БЫДЛО

BSD лучше линукса по многим параметрам кроме одного - юзабельности.

покупаю комп - могу поставить линукс. Хочу BSD - нужно читать с пртистрастием скудный и кривожопый список поддерживаемого железа и строго ему следовать.

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

прочитал man netgraph - ничкего не понял. Дайти пример как с его помощью решаются прикладные задачи администрирования.

Таки загляни в ядро и найди там кучу строчек

MODULE_LICENSE("Dual BSD/GPL");

>BSD лучше линукса по многим параметрам кроме одного - юзабельности. покупаю комп - могу поставить линукс. Хочу BSD - нужно читать с пртистрастием скудный и кривожопый список поддерживаемого железа и строго ему следовать. таже хрень и с софтом - под линукс худо-бедно пишется-портируется что-то, под фрю кроме опенсорса нет ничего. А то что есть - пускается через эмуляцию того же линукса. В общем академическое изделие конечно идеологически - с академической точки зрения - лучше ремесленной поделки. Но для ремесла - то бишь работы - ремесленная поделка пригодна а академисческое изделие увы нет.

Ну хз хз с железом у меня 6.3 и 7.0 встали на ура но новенький 4х ядерник и на плату с xi38

Все софтинки GNU есть в портах и никто не мешает установить, так дял справки в фре щас около 17.5 тыс портов под amd64 в дебиане примерно 18 тыс, чего спрашиается нехватает? Эмулятор в БЗД это не костылявый эмулятор как вайн в линуксе, эмуль в бзд ядерный и падения производительности нету практичестки. что для свисто перделок роли не играет.

с выходом 7й ветки бзд забила 2 бреши серьёзных по которым она уступала. это планировщит и файловая система. последине хоть и эксперементал пока но работает пока без нареканий на покрейнеймере у меня.

На дасктопе гном выглядит без допиливаний замечательно, кеды приёдтся подпилить в плане шрифтов.

>> netgraph
>А вот этой вкусняшки в лупиксе никогда не будет :)

скажите, а что в нём такого? ну да, можно как из кубиков что-то собирать...

А зачем, кроме как трафик считать?

и всё это с риском "1 ошибка = упало ядро".

>А по-моему, нормально. Ты не обосновал свою цифру.

Обосновал (в первом посте): 200 кадров в секунду, 1000 физических запросов к диску в секунду.

А что касается сети -- да, 1G бит сетью можно забрать 100% цпу. Но это и 10G -- специфичные технологии... и специфичные баги vmsplice, страдать от которых приходится всем.

> Потому что последовательность "прочитать порт; проанализировать значение; в зависимости от результата прочитать еще один или другой порт" векторизации не поддается.

А такое НАДО векторизовать? Сомневаюсь, что хотя бы 1% пропускной способности AGP идет по такому сценарию :-)

> Допустим, VM нужно прочитать с диска страницу (одну), а слою TCP - принять пакет (один) - как это векторизовать?

Вот и надо протестировать: читаем весь жесткий диск и замеряем расход ЦПУ на это. Будет видно надо ли вообще заморачиваться ЗДЕСЬ с векторизацией.

Короче идея: time 'cp /dev/hda > /dev/null'

Смотреть: сис. время.

> "There are lies, damned lies and benchmarking results" (c)

Да ладно... поплачу пару дней что миникс жрет цпу вдвое больше, и потом пройдет :-)

>> Хотя бы идею подай, да и прога я думаю в 300 строк вполне уложится...

> Не уложится. Ближайший к реальности тест, который я могу придумать - взять простой драйвер GigE, близкий по исходникам между Minix3 и Линукс, и проверить его на передачу UDP-трафика _без_ использования jumbo frames - смотреть не только на скорость (она может быть одинаковой), но и на потребление ресурсов ЦП

А что собственно сложного? Натолкать удп пакетов? < 300 строк вместе с обработкой аргументов ком. строки.

> Короче идея: time 'cp /dev/hda > /dev/null'

Щас скажут "к логопеду" -- да, правильно, к логопеду

time cp /dev/hda /dev/null

> Ы? Речь шла о том, что запрос на чтение порта работает через сисколл, это не запросы к драйверу, а запросы из самого драйвера. Никакое объединение запросов здесь не сработает.

SYS_VDEVIO

Впрочем вопрос сводится опять к "прочел, проанализировал, прочел другое"

А кто так работает? Какие драйверы?

_______________________________

А каковы недостатки сегментации?

>>Я лично согласен за это платить 10% от проца. И может даже 20%.

>Запусти qemu, выдели свое устройство и хоть обзапускайся.

>Смысл в том, что если повиснет оно и еще и шину за собой потащит, то микроядро не спасет.

Поподробней можно? Как можно повиснуть и потащить за собой шину?

> А так можно давать лабу "добавление страничной виртуальной памяти в Minix3" (или что там тебе угодно).

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

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

>Тогда чего вы удивляетесь, когда пользователи других операционок видят аналогичные тесты, проводимые IBM, Novell, Red Hat и др. linux-компаниями и расценивают их аналогично - высосаный из пальца get the facts от linux?

getthefucktsы пишут слабые. Linux'у getthefuckts не нужен.

>Жизнь была бы намного лучше, если бы студенты делали реально полезные вещи.

Just remember Linus Torvalds, Luke ;)

> таже хрень и с софтом - под линукс худо-бедно пишется-портируется что-то, под фрю кроме опенсорса нет ничего. А то что есть - пускается через эмуляцию того же линукса.

Бугага... дитё, Ты хоть видело FreeBSD, там портов сейчас почти 18000, дистрибутивов в которых столько софта в Линукс, можно по пальцам пересчитать, через эмулятор Linux ядра работает очень малый процент программ, разработчики которых криворуко написали софт, только под Линукс, напоминает венду, написали только под себя, а потом Линукс вайн юзает, так и тут...;)

>Тогда чего вы удивляетесь

кто сказал, что я удивляюсь? не надо за меня расписываться :)

>getthefucktsы пишут слабые. Linux'у getthefuckts не нужен.

Если linux такой сильный, то почему у него всего порядка 1-2% на десктопах?

>> А по-моему, нормально. Ты не обосновал свою цифру.

> Обосновал (в первом посте): 200 кадров в секунду, 1000 физических запросов к диску в секунду.

Это не обоснование. В частности, для вывода 1 кадра может понадобиться 2 системных вызова :D Ну и вообще - серверные нагрузки, где одновременно работа/т диски, сети, таймеры...

> Вот и надо протестировать: читаем весь жесткий диск и замеряем расход ЦПУ на это.

И что именно это замеряет?

> и специфичные баги vmsplice

Да ты видел эти "специфичные баги"? Обычная, скучная пропущенная проверка доступа.

> А что собственно сложного? Натолкать удп пакетов? < 300 строк вместе с обработкой аргументов ком. строки.

Ты упорно не считаешь 2 "достаточно похожих" драйвера для разных ОС.

>> FreeBSD это, между прочим, UNIX, а его пытаются пинать с начала 70- х, и, пока, безуспешно...

Если быть точным, то именно FreeBSD появилась в году эдак 93-м. И пинается она вполне хорошо. Просто то, что привинчивается, то остается всерьез и надолго. А курятник по имени linux скоро развалится..

> скажите, а что в нём такого? ну да, можно как из кубиков что-то собирать...

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

> А зачем, кроме как трафик считать?

А кто им трафик считает? Если только netflow им генерить - но это изврат.

PS. А у вас в линуксе до сих пор полосу через tc режут, тогда как в ipfw пайпы лет ндцать есть?

>Если быть точным, то именно FreeBSD появилась в году эдак 93-м. И пинается она вполне хорошо. Просто то, что привинчивается, то остается всерьез и надолго. А курятник по имени linux скоро развалится..

Точную дату не назовёте ? ;)

>Если linux такой сильный, то почему у него всего порядка 1-2% на десктопах?

Потому что для десктопа главное не сила а

1) "Привычность"
2) Обратная совместимость

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

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

Ога. В FreeBSD отсутствуют целые _классы_ программ потому как фряшное ядро не поддерживает целые _классы_ железа.

Расскажи нам сейчас сказки про вендоров, которые сдлали кривое железо которое фряшники никак не осилили :)

>там портов сейчас почти 18000, дистрибутивов в которых столько софта в Линукс, можно по пальцам пересчитать

Хватит впритык ;)

только дистрибутивов с >20000 пакетов около десятка ... примерно столько же где пакетов >15000

Курите матчасть http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions

> Курите матчасть

Не курю, это вредная привычька, надеюсь Вы Ubuntu, Kubuntu и Xubuntu не считаете за разные дистры, всё же это не совсем коректно, ибо они отличаються только DE, если считать, что Ubuntu, Kbuntu и Xubuntu это разные дистры, а так да, там их действительно 10, а у Вас пальцев сколько??;) Дистров с 15000 тысячами, там вообще 3 штуки, ну даже есть взять ещё 135000 то будет 4, где Вы там почти столько же уведили??:-\ Единственное я вот например не понял, как считают пакеты, все версии одного пакета за один или все пакеты которые просто есть в репозитории, при этом и пакет разной версии одной софтины, пролейте мне свет...:)

>Точную дату не назовёте ? ;)

Скоро :)) И признаки тому уже есть. Разве Линус уже перешел на ГПЛv3?

>> Скоро :)) И признаки тому уже есть. Разве Линус уже перешел на ГПЛv3?

Подозреваю что GPLv3 будет хорошим стимул для развития фряхи. :-D Т.к. коммерческие продукты, с не open-source моделью охотнее будут пользоваться ей и охотнее отдавать обратно.

Еще раз говорю. Линукс - большой курятник с пристройками. И чем дальше, тем тяжелее это поделие поддерживать. Постоянно что-то отваливается.