Ещё одна священная война: mainframes vs x86 servers

Dmitry67 · Post by **Dmitry67** » 22 Jun 2007 19:29

Честно скажу, не знаю. Однако я пока не вижу ничего ПРИНЦИПИАЛЬНО иного в МФ. Я вижу другие подходы к достижению тех же целей - МП/МЗ. И все.

Думаю разница Windows<->Unix на Intel примерно такого же порядка, как Windows<->МФ

f_evgeny · Post by **f_evgeny** » 22 Jun 2007 19:30

zVlad wrote:
Brazen wrote:....
zVlad wrote:Вообще говоря я имел в виду структуру памяти в z/OS. Принцип работы z/OS таков ...

Ничего нового не увидел. Возможно, все это впервые появилось именно в МФ, но сейчас все это есть на писюках, и давно.

Насколько я понял мнение других специалистов по Интел/Windows (Flash-04, Dmitry67) расходится с Вашим. Они утверждают что приложения в Windows "не видят" ядра системы.
Так что же такое система с точки зрения приложения Windows? Linux? Unix? Давайте сопоставим.

Ну, в общем, система это libc.

zVlad · Post by **zVlad** » 22 Jun 2007 19:31

Brazen wrote:
zVlad wrote:Я думаю что это разные вещи. 2-way.....

Не вижу разницы между этими модными словечками и сегментными регистрами x86. Все то же самое было и в реальном режиме, только без защиты памяти и по 64К на сегмент, а сейчас по 2 гига что-ли? Давно я всякие "Undocumented Windows" не читал.
...

Ничего себе модные слова! Я же писал, это конец 70-х в истории эволюции МФ. 4-way - это начало 90-х.
А вот что такое сегментные регистры x86, я так пока и не понял. Flash-04 говорил что это чтобы расширить виртуальное адресное пространство x86. Мои "модные" словечки совсем о другом.

zVlad · Post by **zVlad** » 22 Jun 2007 19:41

Dmitry67 wrote:Честно скажу, не знаю. Однако я пока не вижу ничего ПРИНЦИПИАЛЬНО иного в МФ. Я вижу другие подходы к достижению тех же целей - МП/МЗ. И все.

Думаю разница Windows<->Unix на Intel примерно такого же порядка, как Windows<->МФ

Если Вы, Дима, не знаете что есть система с точки зрения приложения в Windows, то как же Вы можете утверждать одвременно что "я пока не вижу ничего ПРИНЦИПИАЛЬНО иного в МФ", и в то же время, что "Я вижу другие подходы к достижению тех же целей - МП/МЗ". Да цели одни, и подходы действительно разные, хотя в некотором приближении эти подходы действительно могут казаться принципиально одинаковыми. В этом особенность компьютеров и программирования.
Сколько раз мне приходилось осознавать что вещи называемыми принципиально разными на самом деле оказывались по существу одним и тем же (.NET и Java, например. Сейчас меня начнут "убивать"), и наоборот действительно существенно различные вещи в глазах некоторых оказываются ПРИНЦИПИАЛЬНО одним и тем же (МФ и x86, например).

Palych · Post by **Palych** » 22 Jun 2007 19:44

zVlad wrote: В VM, каждая ВМ "видит" память ВМ от адреса 0 до максимального и вправе использовать любой адрес как угодно, вся память от 0 до максимума доступна и для чтения и для записи. ОС ВМ сожет иметь разделяемые с другими аналогичными ОС ВМ области памяти, это во-первых должно быть задано внешним по отношению к ВМ образом, а именно в описании хр. системы, и во-вторых не запрещает ОС ВМ модифицировать саму себя в точ числе в описаных как разделяемые областях памяти. Просто СР создаст тогда уже индивидуальную копию памяти такой ВМ.

То есть - Copy On Write?

Brazen · Post by **Brazen** » 22 Jun 2007 20:10

zVlad wrote:
Brazen wrote:....
zVlad wrote:Вообще говоря я имел в виду структуру памяти в z/OS. Принцип работы z/OS таков ...

Ничего нового не увидел. Возможно, все это впервые появилось именно в МФ, но сейчас все это есть на писюках, и давно.

Насколько я понял мнение других специалистов по Интел/Windows (Flash-04, Dmitry67) расходится с Вашим. Они утверждают что приложения в Windows "не видят" ядра системы.

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

В свое время на надежность NT4 ругались, потому что у нее видеодрайверы работают в нулевом кольце, а не в третьем, как у NT3.51. Сыпучий драйвер мог запросто обрушить всю систему. Кстати, просто программа и драйвер по разному собираются и по-разному выполняются. Так что драйверы может и видят ядро, я не в курсе.

dB13 · Post by **dB13** » 22 Jun 2007 20:37

zVlad wrote:Если, как я понял из Ваших реплик, в адресном пространстве пользователя нет кода ядра системы, то тогда код ядра находится... а действительно где он находится у Windows? В своем собственном адресном пространстве? Но тогда ему должно быть недоступно адресное пространство пользователя...

Здесь zVlad прав.
В Windows в адресном пространстве пользователя есть код и данные ядра но они обычно не видны программам пока они выполняются в user space / ring 3. Как только программа делает системный вызов и начинает выполнять код ядра / ring 0, то код и данные ядра сразу становятся доступными, при этом данные и код пользователя остается на тех же адресах. При системных вызовах не происходит смены page tables поэтому на 32-bit Windows суммарное адресное пространство (user+kernel) ограничено 4 GB (2+2 или 3+1).

На x86 Linux может быть по-другому: page tables могут сменяться при системных вызовах и давать 4GB+4GB ("4GB/4GB split patch"), но переключение page tables -- дорогая операция и замедляет системные вызовы и доступ к user mode data.

f_evgeny · Post by **f_evgeny** » 22 Jun 2007 20:43

Brazen wrote:В свое время на надежность NT4 ругались, потому что у нее видеодрайверы работают в нулевом кольце, а не в третьем, как у NT3.51. Сыпучий драйвер мог запросто обрушить всю систему. Кстати, просто программа и драйвер по разному собираются и по-разному выполняются. Так что драйверы может и видят ядро, я не в курсе.

В NT драйвера - часть ядра. Поэтому и синий экран. В Линуксе и BSD тоже. В QNX - нет.

zVlad · Post by **zVlad** » 22 Jun 2007 21:14

Palych wrote:
zVlad wrote: В VM, каждая ВМ "видит" память ВМ от адреса 0 до максимального и вправе использовать любой адрес как угодно, вся память от 0 до максимума доступна и для чтения и для записи. ОС ВМ сожет иметь разделяемые с другими аналогичными ОС ВМ области памяти, это во-первых должно быть задано внешним по отношению к ВМ образом, а именно в описании хр. системы, и во-вторых не запрещает ОС ВМ модифицировать саму себя в точ числе в описаных как разделяемые областях памяти. Просто СР создаст тогда уже индивидуальную копию памяти такой ВМ.

То есть - Copy On Write?

Так точно. Разница по-видимому в том что в cлучае Copy On Write это распространяется на страницу, в то время как в VM это распространяется на весь сегмент (набор страниц) в целом и сразу.

Dmitry67 · Post by **Dmitry67** » 22 Jun 2007 21:20

Очевидно, Copy On Write экономнее

zVlad · Post by **zVlad** » 22 Jun 2007 21:26

dB13 wrote:
zVlad wrote:Если, как я понял из Ваших реплик, в адресном пространстве пользователя нет кода ядра системы, то тогда код ядра находится... а действительно где он находится у Windows? В своем собственном адресном пространстве? Но тогда ему должно быть недоступно адресное пространство пользователя...

Здесь zVlad прав.
1. В Windows в адресном пространстве пользователя есть код и данные ядра но они обычно не видны программам пока они выполняются в user space / ring 3. Как только программа делает системный вызов и начинает выполнять код ядра / ring 0, то код и данные ядра сразу становятся доступными, при этом данные и код пользователя остается на тех же адресах. При системных вызовах не происходит смены page tables поэтому на 32-bit Windows суммарное адресное пространство (user+kernel) ограничено 4 GB (2+2 или 3+1).

2. На x86 Linux может быть по-другому: page tables могут сменяться при системных вызовах и давать 4GB+4GB ("4GB/4GB split patch"), но переключение page tables -- дорогая операция и замедляет системные вызовы и доступ к user mode data.

1. Кстати, безусловно и в z/OS ядро находящиеся в виртуальных адресах приложения приложению не доступно, поскольку память ядра имеет ключ защиты памяти "0", а приложение выполняется с ключом защиты ^= "0". Когда же происходит системный вызов... и т.д. по тексту выше, с тем лишь дополнением что приложение может образовывать secondary address space и даже больше чем secondary.

2. Цена такой операции на МФ, как я понимаю, affortable как раз бладодаря механизмам 2-way, 4-way, and Access Registers. Как я понимаю Linux на x86 "симулирует" вторые 4GB программно (поправьте если я не прав), поэтому и дорого это стоит. На МФ - это аппаратная фича и потому широко используется.

zVlad · Post by **zVlad** » 22 Jun 2007 21:32

Dmitry67 wrote:Очевидно, Copy On Write экономнее

Дело здесь не в экономичности. Это совершенно разные принципы работы систем. На системах МФ мы или разделяем память, и достигается это конфигурацией системы, или не разделяем. На системах x86 мы не конфигурируем систему для разделения, система "старается" максимально разделять, но если (по любой причине) это не получается система делает copy-on-write.

На мой взгляд это очень разные вещи. Особенно принимая во внимание тот факт что copy-on-write в системах МФ - это скорее исключение, весьма редкая ситуация, практически нулевая вероятность. Т.е. то что мы хочем разделять и в самом деле разделяется.

Palych · Post by **Palych** » 22 Jun 2007 21:41

zVlad wrote: Дело здесь не в экономичности. Это совершенно разные принципы работы систем. На системах МФ мы или разделяем память, и достигается это конфигурацией системы, или не разделяем. На системах x86 мы не конфигурируем систему для разделения, система "старается" максимально разделять, но если (по любой причине) это не получается система делает copy-on-write.

На мой взгляд это очень разные вещи. Особенно принимая во внимание тот факт что copy-on-write в системах МФ - это скорее исключение, весьма редкая ситуация, практически нулевая вероятность. Т.е. то что мы хочем разделять и в самом деле разделяется.

Не вижу разницы с тем как это делает VMWare.
Точнее - не вижу что принципиально даёт возможность конфигурирования.

zVlad · Post by **zVlad** » 23 Jun 2007 00:03

Palych wrote:
zVlad wrote: Дело здесь не в экономичности. Это совершенно разные принципы работы систем. На системах МФ мы или разделяем память, и достигается это конфигурацией системы, или не разделяем. На системах x86 мы не конфигурируем систему для разделения, система "старается" максимально разделять, но если (по любой причине) это не получается система делает copy-on-write.

На мой взгляд это очень разные вещи. Особенно принимая во внимание тот факт что copy-on-write в системах МФ - это скорее исключение, весьма редкая ситуация, практически нулевая вероятность. Т.е. то что мы хочем разделять и в самом деле разделяется.

Не вижу разницы с тем как это делает VMWare.
Точнее - не вижу что принципиально даёт возможность конфигурирования.

Если перефразировать одно из изречений одного из философов, то можно сказать что человек видит тоько то что он хочет видеть.
В этой нашей "священной" войне, вообще говоря, есть только один положительный элемент - это то что она показывает насколько люди привыкают к чему-то, что даже перестают воспринимать (я бы даже сказал сопротивляются) другое, особенно если это другое где-то рядом, смежное, но тем не менее другое. Я кстати, тоже не исключение.
Возращаясь к теме, я бы все таки начал с того что что разница в подходах все таки есть и Вы сами говорите: "не вижу что принципиально даёт возможность конфигурирования", вот в этом и состоит основная разница. Конфигурирование основывается на знании того какие именно области память могут быть разделяемыми. В случае z/OS, область LPA -это область куда кладутся ре-ентерабельные (я думаю все знают что это такое) программы, их специально так пишут что их можно разделять и они сами себя никогда не модифицируют. Следовательно, если у нас в системе выполняется много экземпляров чего-нибудь одного, а на МФ это очень и очень обычное явление, и эти экземпляры имею хорошо составленный набор таких программ, то экономия реальной памяти просто несомнена.
Далее поскольку мы изначально определили разделяемые ресурсы системе "легче" эту разделяемость поддерживать: системе не надо делать предположений, ей не надо суетиться когда какой-либо процесс пытается нарушать договоренности - это просто убивают. И в итоге все это оказывается не благими намерениями, а эффективным работающим механизмом.
Вот интересно было бы узнать насколько высок рэйтинг разделения в реально работающем сервере на x86. Я думаю не высок хотя бы потому что есть правило - один сервер/одно приложение.

FomaKinyaev · Post by **FomaKinyaev** » 23 Jun 2007 00:16

zVlad wrote: ре-ентерабельные (я думаю все знают что это такое) программы, их специально так пишут что их можно разделять и они сами себя никогда не модифицируют.

На x86 все программы по умолчанию получаются реентерабельными в силу правильности архитектуры.