URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 12479
[ Назад ]

Исходное сообщение
"OpenNews: Краткое сравнение ядер Solaris, Linux и FreeBSD."

Отправлено opennews , 17-Окт-05 07:40 
Статья "A Comparison of Solaris, Linux, and FreeBSD Kernels (http://www.opensolaris.org/os/article/2005-10-14_a_compariso.../)" отражает взгляд специалиста по внутреннему устройству Solaris на различия планировщиков задач, систем управления памятью и организации файловой системы в ядрах Solaris 10, Linux 2.6.x и FreeBSD 5.3.

URL: http://www.opensolaris.org/os/article/2005-10-14_a_compariso.../
Новость: http://www.opennet.me/opennews/art.shtml?num=6266


Содержание

Сообщения в этом обсуждении
"Краткое сравнение ядер Solaris, Linux и FreeBSD."
Отправлено Moralez , 17-Окт-05 07:40 
"If the memory shortage is severe enough, vm_pageout_scan will kill the largest process on the system". (FreeBSD)

Разве?


"Краткое сравнение ядер Solaris, Linux и FreeBSD."
Отправлено Аноним , 17-Окт-05 09:51 
>"If the memory shortage is severe enough, vm_pageout_scan will kill the largest
>process on the system". (FreeBSD)
>
>Разве?

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


"Краткое сравнение ядер Solaris, Linux и FreeBSD."
Отправлено Аноним , 17-Окт-05 09:54 
У меня под Linux есть процесс с "size" 400Мб и RSS 5 Мб. Причем в системе всего 128 Мб памяти, при этом занятость свопа нулевая. Я все недоумеваю, как такое может быть.

"Краткое сравнение ядер Solaris, Linux и FreeBSD."
Отправлено kaa , 17-Окт-05 11:55 
bzip'ает он её(память), bzip'ает :)

"Краткое сравнение ядер Solaris, Linux и FreeBSD."
Отправлено Аноним , 17-Окт-05 11:56 
и что такого?

"Краткое сравнение ядер Solaris, Linux и FreeBSD."
Отправлено DEC , 17-Окт-05 11:58 
Всё оч. просто. Он эту память заказал, но не заполнил данными.

"Краткое сравнение ядер Solaris, Linux и FreeBSD."
Отправлено Аноним , 17-Окт-05 12:04 
>Всё оч. просто. Он эту память заказал, но не заполнил данными.

Каким образом заказал ? Как я понимаю, если сделан malloc, то память уже используется, отследить пишется туда что-то или нет невозможно.
mmap'ом тоже такого не добиться, это вам не диск где можно создать "дырявый" файл.


"Краткое сравнение ядер Solaris, Linux и FreeBSD."
Отправлено Andrew , 17-Окт-05 13:07 
> Каким образом заказал ? Как я понимаю, если сделан malloc, то память уже
> используется, отследить пишется туда что-то или нет невозможно.
> mmap'ом тоже такого не добиться, это вам не диск где можно создать
> "дырявый" файл.

malloc выдяет некую область памяти в виртуальном адресном пространстве процесса. Страницы физической памяти выделяются при первом обращении к конкретному адресу памяти на чтение или запись (в процессе обработки page fault).


"Краткое сравнение ядер Solaris, Linux и FreeBSD."
Отправлено Аноним , 17-Окт-05 13:08 
Насколько я помню, в винде это называется резервированием памяти, т.е. резервируется часть _виртуальной_ памяти (точнее только адресное пространство), а сама отдача памяти проиходит только в случае обращения к ней (к зарезервированному участку), причем добавляется память постранично.

"Краткое сравнение ядер Solaris, Linux и FreeBSD."
Отправлено Slayer , 17-Окт-05 15:34 
В VSZ, насколько я понимаю, входит очень многое, в том числе mmap'ed файлы и т.д.

"Краткое сравнение ядер Solaris, Linux и FreeBSD."
Отправлено Dmitry U. Karpov , 18-Окт-05 02:37 
Это всё очень просто... для тех, кто понимает. ;)

Итак, общеизвестно, что адресное пространство задачи процесса состоИт из страниц; т.е. у каждого процесса есть таблица дескрипторов страниц, а элементы таблицы (дескрипторы) ссылаются на четырёхкилобайтные куски памяти (т.е. содержат адресА этих кусков). {Дискуссия о том, что у разных архитектур разный размер страницы, откладывается.} При этом никто не мешает нескольким дескрипторам (или разных таблиц) ссылаться на одну и ту же страницу.

Допустим, некий процесс делает fork(); будет ли при этом копироваться вся его память (и код, и данные)? Нет, т.к. есть лучший способ - у обоих процессов делаются одинаковые таблицы дескрипторов, но все данные помечаются как ReadOnly ("замораживаются"); если один из процессов модифицирует содержимое страницы, то только тогда создаётся копия этой страницы, таблицы обоих процессов модифицируются, модифицированная одним из процессов страница "размораживается" для обоих процессов. (Если fork() делался дважды и более, ситуёвина немного сложнее, но примерное представление я уже дал.)

Кстати, код у всех процессов, порождённых одним файлом, всегда общий - т.е. два юзера запустили /bin/csh, а код занимает место в памяти один таз (это порождает свои напряги - например, при сбросе и при подкачке кода надо модифицировать таблицы дескрипторов страниц для всех процессов).

Что-то меня занесло - надо вернуться к теме.
Итак, процесс делает alloc(...); по стандарту ему должны вернуть адрес куска памяти, заполненного нулями (случай "нет тебе у меня ресурсов!" не рассматриваем). А на фига выделять процессу память и заливать её нулями, когда можно взять одну страницу, изначально заполненную нулями, и все дескрипторы страниц, отвечающие за аллокированный кусок памяти (или точнее, адресного пространства), "заморозить" и направить на эту страницу (изначально заполненную нулями)? Когда надо будет (т.е. когда процесс захочеть записАть в одну из страниц данные), произойдёи exception, по которому ядро выделит процессу память, поменяет в таблице дескриптор этой страницы и вернёт управление процессу.
Интересное следствие: Процесс может делать alloc(сколь_угодно_много), отказа ему не будет даже в том случае, когда он просит больше, чем суммарный размер оперативки и свопа; зато память (и виртуальная тоже) может кончиться в совершенно произвольный момент (ну, не совсем произвольный, а в момент записи данных в аллокированную область).

Кстати, аналогично делается с файловой системой. Операции
    open(новый_файл);
    lseek(от_начала,куда_подальше);
    write(один_байт);
создадут файл большого размера; но место на диске уменьшится весьма незначительно. И механизм тут тот же самый: все залитые нулями кластеры - это один общий для всех файлов кластер (ну, не для всех, а для тех, кому нужен такой кластер).

PS: Перечитал вопрос и понял, что м.б. ещё проще: процесс имеет нехилого размера экзешник и задействует тучу динамических библиотек. Часть кода находится в памяти, остальное просто в данный момент не нужно. Надеюсь, все тут в курсе, что при запуске программы и подключении динамических библиотек те файлы, в которых лежат код и данные программы и библиотек, присоединяются к свопу? Иными словами, имея 16 MB RAM + 20 MB Swap я запросто могу запустить стомегабайтную программу - лишь бы модифицируемые данные не превысили 36 MB (про память, занимаемую ядром, я забыл и вспоминать не хочу; это - самостоятельная работа на дом).

PPS: Если кто хочет, чтобы я это преподавал - обращайтесь в СтинсКоман http://www.infosystems.ru


"Про работу с памятью"
Отправлено Антон , 18-Окт-05 09:53 
Можно вопросы по теме ?

Как работает механизм осовобождения памяти в Linux ?
Я так понимаю, что когда процесс вызывает free(), то реально память не становится доступной для других процессов, а остается как-бы за текущим, на случай если он опять запросит память.

Можно ли расчитать, сколько физической памяти жрет процесс, или только примерно смотря на RSS ?


"Про работу с памятью"
Отправлено _Nick_ , 18-Окт-05 10:48 
>Можно вопросы по теме ?

нужно

>Как работает механизм осовобождения памяти в Linux ?
отлично

>Я так понимаю, что когда процесс вызывает free(), то реально память не
>становится доступной для других процессов, а остается как-бы за текущим,
>на случай если он опять запросит память.
да. Реально память НЕГАРАНТИРОВАННО освобождается. И БЕЗ "как-бы" остается  на считу у текущего процесса.
malloc() и free() - это функции glibc, которые управляют размещением памяти процесса.
А размер самой памяти (виртуальный) занимаемый процессом меняется системным вызовом brk(). Так malloc() с большой вероятностью увеличит размер процесса. А вот free() [практически] никогда не уменьшает его :)
А зачем? ведь, как ты сказал, через пару сек malloc() затребует памяти и опять двигать границу процесса - лишняя нагрузка на подсистему памяти.
А если процесс отхапал много и не пользует и не отдает - то свалится в своп при необходимости ;)

>Можно ли расчитать, сколько физической памяти жрет процесс, или только примерно смотря
>на RSS ?
смотри /proc/<PID>/status
точнее вряд ли тебе понядобится ;) а если и понадобится, то все равно эта цыфра может меняется несколько сот раз в секунду ;)))))))  тогда бери дебаггер в руки %)


"Про работу с памятью"
Отправлено wulf , 19-Окт-05 01:24 
>>Как работает механизм осовобождения памяти в Linux ?
>отлично

Благородный дон не кинет ли, случайно, в массы ссылочкой как memory management работает в 2.6 ядрах, а то, простой поиск в гугеле наталкивается на заметки Rik van Riel про то как он (memory mangement)хреново работает в 2.2 и как с этим собираются бороться в 2.4, как из этого мало чего хорошего получилось в 2.4.10 и какое количество новых революционных идей с названиями на подобие AdvancedPageReplacement они собираются реализовать в будущих ядрах.
Желательно в доступном изложении а-ля http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-desig...
Ведь там (в 2.6) много чего реально сделали для борьбы с этой традиционной проблемой линукса. Только, к сожалению, эта инфа теряется среди репортов о предыдущих неудачах


"Про работу с памятью"
Отправлено _Nick_ , 19-Окт-05 10:29 
а знаешь анекдот про то, как работает мотор???

вот как спросил - так я и ответил

Хотел бы описаниия - сказал бы опиши процесс, аглоритмы, плюсы/минусы....


Ну ты загнул про проблемы 2.2 ядра... и про их решение в 2.4
я в этом вижу тупую зад3.14чку.

Это ты пойди еще бсдшнику зачитай про глюки в 3.5 бзде..
куда тебя пошлют??  И почему я должен поступить по-иному.

Знаешь ведь, что как минимум 2.6 ветку нонче стоит обсуждать.

> Ведь там (в 2.6) много чего реально сделали для борьбы с этой традиционной проблемой линукса.

хотелось бы узнать эту твою проблему Линукса...

> Только, к сожалению, эта инфа теряется среди репортов о предыдущих неудачах

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

Интересно какие же это у Линуха были такие огромные предыдущие проблемы, что они могут помешать моей тачке бегать под 2.6 быстрее чем под чем угодно другим??


"Про работу с памятью"
Отправлено Vasya , 19-Окт-05 13:24 
>Интересно какие же это у Линуха были такие огромные предыдущие проблемы, >что они могут помешать моей тачке бегать под 2.6 быстрее чем под чем >угодно другим??

Линух никогда на десктопе не будет работать быстрее Винды! Винда заточена под десктопы и там все работает намного быстрее особенно мультимедиа и игрушки. Поэтому хватит тут орать про свой Линух ты уже всех им достал. Если б ты разбирался в архитектуре осей, то молчал бы и не вы*лся, токо ламеры орут так как ты. Открой глаза пошире, мир разнообразен :) не стоит на него смотреть сквозь призму одной единственной и далеко не лучшей оси


"Про работу с памятью"
Отправлено _Nick_ , 19-Окт-05 14:57 
>Линух никогда на десктопе не будет работать быстрее Винды! Винда заточена под
>десктопы и там все работает намного быстрее особенно мультимедиа и игрушки.

Винда те нарисует быстро одно окно. Ну два. А если задача усложняется - то скажи ей досвиданья. А если недай бог еще кому-то нужно удаленно зайти поработать - лучше пойти пива попить пока он залогиниться. Под линухом
неск. человек могут нормально работать иксами НА ОБЫЧНОМ компе, без излишних наворотов под выньдовый теорминал сервант с 2гигами мозгов и парой процов для тех же неск человек. В сад.

Про mpeg4 на 300 целке напомнить? винда отсасывала вовсю - низя было смотреть. Под Линухом mplayer крутил это дело запросто - ни тормоза, ни глюка. Ну а если говорить о современном железе, то был тест в нете (интересно - сам найдешь) сколько медиа плееров может потянуть Линух и маздай. Маздай после 5 окна с фильмом начал сильно задумываться и тужиться. Альтлинух кажись у них был (по дефолту поставленный) - 11 mplayer'ov его не напрягли. 12 уже был выше нормы.

А насчет игр... Странно.
Если винда такая классная и заточенная под игры, то почему у меня UT2004 под Линухом на 7fps больше дает??  Я что-то неправильно делаю?? ;)

>Поэтому хватит тут орать про свой Линух ты уже всех им
>достал.
он достал только близоруких (в плане знаний) челов, которые о%уевают от мысли, что их любимая винда - всего лишь приманка мс, чтоб сбить бабла и сделать лохами всех и вся. Ну и еще красноглазых (тока красноглазых) бздшников рассказы о линухе напрягают.

>Если б ты разбирался в архитектуре осей, то молчал бы
>и не вы*лся
и разбираюсь, но и почему-то не молчу :)
А ты наверное решил, что если у меня мнение не совпадает с твоим - значит я нихрена не знаю?? Ну, это, прямо скажем, не метод определения уровня знаний. Спроси если чего не знаешь про Линух - я те расскажу ;)
И тебе будет полезно и увидишь как работает ядро общего назначения %)


>токо ламеры орут так как ты.
да. ламмеры иногда точно также орут. Слышали может что ;)

>Открой глаза пошире, мир разнообразен :)
офигенно согласен %)
есть еще пиво, деФки, рок, поспать и т.д. ;))

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

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

занешь как страшно стало.....:||

решил что-то менять - как видишь, получилось ;)))


"Про работу с памятью"
Отправлено Vasya , 19-Окт-05 16:12 
Ну насчет Винды я пошутил, я и сам ее не воспринимаю как полноценную ось :)) Но считать Линух панацеей от всего - это тоже ошибочное мнение. В некоторых задачах Линух действительно рулит, но есть задачи, с которыми другие оси справляются лучше. На моей тачке стоит Линух, Фря, Солярка,был еще нетбсд, но я снес недавно(оптимизация дискового пространства ;)) )
В качестве домашней мультимедиа-станции я линухом доволен, ну а т.к я работаю с Жабой, то лучшей платформы чем Солярка для нее не вижу. Жаба-сервлеты + оракл - производительность намного выше чем в любой другой оси

"Про работу с памятью"
Отправлено FreeSTYLE , 20-Окт-05 00:01 
>>Линух никогда на десктопе не будет работать быстрее Винды! Винда заточена под
>>десктопы и там все работает намного быстрее особенно мультимедиа и игрушки.
>
>Винда те нарисует быстро одно окно. Ну два. А если задача усложняется
>- то скажи ей досвиданья. А если недай бог еще кому-то
>нужно удаленно зайти поработать - лучше пойти пива попить пока он
>залогиниться. Под линухом
>неск. человек могут нормально работать иксами НА ОБЫЧНОМ компе, без излишних наворотов
>под выньдовый теорминал сервант с 2гигами мозгов и парой процов для
>тех же неск человек. В сад.
>
>Про mpeg4 на 300 целке напомнить? винда отсасывала вовсю - низя было
>смотреть. Под Линухом mplayer крутил это дело запросто - ни тормоза,
>ни глюка. Ну а если говорить о современном железе, то был
>тест в нете (интересно - сам найдешь) сколько медиа плееров может
>потянуть Линух и маздай. Маздай после 5 окна с фильмом начал
>сильно задумываться и тужиться. Альтлинух кажись у них был (по дефолту
>поставленный) - 11 mplayer'ov его не напрягли. 12 уже был выше
>нормы.
>
>А насчет игр... Странно.
>Если винда такая классная и заточенная под игры, то почему у меня
>UT2004 под Линухом на 7fps больше дает??  Я что-то неправильно
>делаю?? ;)
>
>>Поэтому хватит тут орать про свой Линух ты уже всех им
>>достал.
>он достал только близоруких (в плане знаний) челов, которые о%уевают от мысли,
>что их любимая винда - всего лишь приманка мс, чтоб сбить
>бабла и сделать лохами всех и вся. Ну и еще красноглазых
>(тока красноглазых) бздшников рассказы о линухе напрягают.
>
>>Если б ты разбирался в архитектуре осей, то молчал бы
>>и не вы*лся
>и разбираюсь, но и почему-то не молчу :)
>А ты наверное решил, что если у меня мнение не совпадает с
>твоим - значит я нихрена не знаю?? Ну, это, прямо скажем,
>не метод определения уровня знаний. Спроси если чего не знаешь про
>Линух - я те расскажу ;)
>И тебе будет полезно и увидишь как работает ядро общего назначения %)
>
>
>
>>токо ламеры орут так как ты.
>да. ламмеры иногда точно также орут. Слышали может что ;)
>
>>Открой глаза пошире, мир разнообразен :)
>офигенно согласен %)
>есть еще пиво, деФки, рок, поспать и т.д. ;))
>
>>не стоит на него смотреть сквозь призму
>>одной единственной и далеко не лучшей оси
>
>слава богу уже давно перестал. Сам был когда-то в шоке, когда подумал
>разок, что кроме мазздайных доса и выньды ничего не видел и
>не умею...
>
>занешь как страшно стало.....:||
>
>решил что-то менять - как видишь, получилось ;)))

Молодой человек ))) А Вы ставили Виндовс терминал сервер ??? )))
Вот я реально делал это для школ ))) Выбирали между линух+опенофис и вин+мс_офис ))) На П4 512М 12терминалов под виндами просто прекрасно работали (видео, ворд, ексел и.т.д.)))) Когда это поставили "Линух-СПЕЦЫ" на такую же машину линух просто сдох ))) Работать на этом блёвове было не возможно ))) Тормоза дикие ))) А вы тут линух-линух )))

Я поклонник FreeBSD но я не говорю что в х-ах она круче чего либо ))) Я даже утверждаю что она не для десктопа ))) Единственный крутой *никс десктоп это MAC OSX ))) А линух ето только на сервер ))) Да и то только при наличии ровных рук )))


"Про работу с памятью"
Отправлено _Nick_ , 20-Окт-05 00:05 
>А линух
>ето только на сервер ))) Да и то только при наличии
>ровных рук )))

тебе видать с ровными руками не очень-то повезло...
(см. "это поставили \"Линух-СПЕЦЫ\"" - значит ставил даже не ты, и даже реально не спецы....  зато винду все спецы ставить...  ну, будьте счастливы)


"Про работу с памятью"
Отправлено Wulf , 19-Окт-05 14:48 
> Хотел бы описаниия - сказал бы опиши процесс, аглоритмы, плюсы/минусы....
Просил ссылку, но спасибо, уже сам сиог отыскать что-нибудь отдаленно похожее:
http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
http://www.linux-mm.org
http://linuxcompressed.sourceforge.net/vm24/
- хотя это все лишь разрозненные куски

> Ну ты загнул про проблемы 2.2 ядра... и про их решение в 2.4
я в этом вижу тупую зад3.14чку.

пожалуйста...
http://www.surriel.com/lectures/linux24-vm.html
http://www.cs.purdue.edu/homes/li/cs690Z/Outline/vmm.pdf

> хотелось бы узнать эту твою проблему Линукса...
MVTS для пропуска одинакового с FreeBSD-шной версией кол-ва звонков требует в 2 раза более мощного процесора. Хотя, эта проблема решаема и относится, скорее, не к VM а или к networking-у, или к самому MVTS.

> Это ты пойди еще бсдшнику зачитай про глюки в 3.5 бзде..
куда тебя пошлют??  И почему я должен поступить по-иному.
> тупая маза. ты небось бсдшник и тебе обидно, что Линух намного шустрее бзди и поэтому несешь такую херню. Бывает. Это вообще сплошь и рядом.
??????????????? Ваше миропонимание мне непонятно. Почему меня должны посылать или мне должно быть обидно, если бы я был бсдшником?

>Интересно какие же это у Линуха были такие огромные предыдущие проблемы, что они могут помешать моей тачке бегать под 2.6 быстрее чем под чем угодно другим??
Какая разница, что было, гораздо интереснее откопать, что есть, а тут, извините, для меня авторитетнее мнение Линуса или Рика или еще какого-нибудь кернел-гуру, нежели Ваше, но отыскать что-нибудь свежее и/или логически структурированое по этой теме для линукса непросто. В отличии от


"Про работу с памятью"
Отправлено Vasya , 19-Окт-05 16:25 
>нежели Ваше, но отыскать что-нибудь свежее и/или логически структурированое по этой
>теме для линукса непросто. В отличии от
Да действительно, таких монументальных трудов как Solaris internals
для Линуха не отыщешь :)
Кое-что интересное можно прочитать у Таненбаума, еще попадалась печатная книга "Ядро Linux", правда там описания ядра 2.2.х


"Про работу с памятью"
Отправлено _Nick_ , 19-Окт-05 16:57 
>>нежели Ваше, но отыскать что-нибудь свежее и/или логически структурированое по этой
>>теме для линукса непросто. В отличии от
> Да действительно, таких монументальных трудов как Solaris internals
>для Линуха не отыщешь :)

а я сейчас читаю 2800002.pdf (~12M) Intel® PXA27x Processor Family Developer’s Manual ;))
Линух прикручиваю к своему КПК
Во где можно кернел девелоперу развернуться....


"Краткое сравнение ядер Solaris, Linux и FreeBSD."
Отправлено _Nick_ , 18-Окт-05 10:21 
>Интересное следствие: Процесс может делать alloc(сколь_угодно_много), отказа
ему не будет даже в
>том случае, когда он просит больше, чем суммарный размер оперативки и
>свопа

а про 3Gb (или 2 для любителей остренького) лимит виртуального размера процесса на i386 мы забыли???  или зачем ламмеров пугать?? да?

>PPS: Если кто хочет, чтобы я это преподавал - обращайтесь в СтинсКоман
>http://www.infosystems.ru

....преподаватель...
с такими "неточностями" будешь азбуку в детсаде повторять..


"Краткое сравнение ядер Solaris, Linux и FreeBSD."
Отправлено rr , 25-Окт-05 19:02 
я тоже венду не воспринимаю как полноценную ось Но считать Линух панацеей от всего - это тоже ошибочное мнение. В некоторых задачах Линух действительно рулит, но есть задачи, с которыми другие оси справляются лучше. На моей тачке стоит Линух, нетбсд, была еще фря, но я снес недавно(оптимизация дискового пространства ;)) )
В качестве домашней мультимедиа-станции я линухом доволен.