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

Palych · Post by **Palych** » 22 Jun 2007 15:32

KP580BE51 wrote:
Palych wrote:Медленно и/или ненадёжно.

Зато реалтаймово. Для ответов о "паламался" можно еще одни интерфейс придумать, пусть даже 495. Этого хватит. Некоторые сайты к примеру иногда гугл не находит. Ну и кого это волнует?

Для гугла - не волнует, а для банковской/кредитной системы - очень даже.
Опять же - требование реалтайма там где он не нужен.
С другой стороны - может отвечать "Нету" и не так страшно? Всего четыре буквы...

zVlad · Post by **zVlad** » 22 Jun 2007 15:36

Zombie416 wrote:
zVlad wrote:Можно еще вопрос? А в Windows используется разделение страниц разничными процессами? Как? Что в этом плане дают (если дают) DLL?

Copy On Write, memory mapped files и т.д. http://support.microsoft.com/kb/100635 или, как писал тов. db13, страницы 30-33 PowerPoint презентации http://www.cs.cmu.edu/afs/cs.cmu.edu/ac ... lass18.ppt

Предвосхищая вопрос, в x86 также имеется поддержка виртуальной памяти

Довольно не внятное объяснение в первом линке:

When you use the LoadLibrary() function in 16-bit Windows or in OS/2, the operating system loads the specified Dynamic-Link Library (DLL) only once. Therefore, the DLL has the same address in every process. However, dynamic loading of DLLs works differently in Windows NT.

The operating system loads a DLL separately for each process because each application has its own address space in Windows NT; the address space is shared in 16-bit Windows and in OS/2. Because the operating system must map pages into the address space for each process, the DLL may be loaded at different addresses in different processes. The memory manager optimizes loading DLLs such that if two processes share the same pages from the same DLL image, they share the same physical memory.
....

Хотя общая идея разделения виртуальной памяти понятна - пытаемся разделять пока это оказывается возможным, если нет то делаем индивидуальные копии. В VMware дополнительно производится анализ на одинаковость контекста в страницах и если они одинаковы то делается их разделение опять же до тех пор пока кто-либо из участников не попытается изменить контекст, тогда получай свою копию.
Иначе в системах на МФ. Фналогом DLL в z/OS можно считать Link Pack Area (LPA). LPA строится из реентерабельных программв системы и приложений во время загрузки системы. После загрузки LPA можно "достраивать" либо добавляю новые программы либо добавляя новые версии уже находящихся в LPA программ. LPA строго защищена от модификаций. Попытка модифицировать LPA вызывает защиту памяти и аварийное завершение нарушителя.
Другой разделяемой областью виртуальной памяти в адрессных пространствах приложений является ядро системы (nucleus). В адресном пространстве каждого приложения в определенных адресах представленно ядро системы.
Есть и другие разделяемые ресурсы памяти. Если что-то сделано разделяемым то как правило попытка модификации это авария. Исключение хранимые системы и сегменты в VM. Если ОС ВМ вдруг решила модифицировать свой сегмент памяти, который объявлен разделенным, то тогда СР создаст такой ВМ отдельную копию всего сегмента и позволит модификацию. В случае ВМ это совершенно естественно.

Brazen · Post by **Brazen** » 22 Jun 2007 16:42

zVlad wrote:Фналогом DLL в z/OS можно считать Link Pack Area (LPA). LPA строится из реентерабельных программв системы и приложений во время загрузки системы. После загрузки LPA можно "достраивать" либо добавляю новые программы либо добавляя новые версии уже находящихся в LPA программ.

DLL + COM

zVlad wrote:Другой разделяемой областью виртуальной памяти в адрессных пространствах приложений является ядро системы (nucleus). В адресном пространстве каждого приложения в определенных адресах представленно ядро системы.

Ну и нахрена? Тем более, что его нельзя изменять. Ядро -- это черный ящик, передал аргументы, получил результат. Что там в ядре, программу не должно интересовать. Соответственно, и распределять ядро на память программы смысла не имеет.

f_evgeny · Post by **f_evgeny** » 22 Jun 2007 16:45

Brazen wrote:Ну и нахрена? Тем более, что его нельзя изменять. Ядро -- это черный ящик, передал аргументы, получил результат. Что там в ядре, программу не должно интересовать. Соответственно, и распределять ядро на память программы смысла не имеет.

Только по моему это везде так.

Dmitry67 · Post by **Dmitry67** » 22 Jun 2007 16:45

На самом деле так в VAX/VMS тоже было сделано
Там в старших 2Gb виднелась read-only система и всякие библиотеки
Сами EXE получались маленькие и разделяли эти библиотеки
Думаю, сертифицировать на чтото систему, где OS видна в памяти процесса, даж RO, тяжело
Если только там никогда не появляются данные ОС

zVlad · Post by **zVlad** » 22 Jun 2007 16:58

Flash-04 wrote:
- 2 way DAT-box, позволяет в одной инструкции адресовать два адрессных пространства одновременно. Может это и у Р6 есть, но я этого в просмотренном материале не увидел. Поздние 70-е.

можно поподробнее? насколько я помню, в 386 можно адресовать память с помощью сегментных регистров, внутри сегментов с помошью смещения. Т.к. сегментных регистров 4, и каждый из них может ссылаться на свое адресное пространство, внутри которого уже действует трансляция виртульного адреса в физический. Таким образом можно увеличить адресуемую память далеко за пределы 4Gb на 386. Другое дело что Win/Linux не используют полностью возможности такой архитектуры. Процесс получает только 4Gb виртуаьной памяти и всё.
Поэтому я еще раз повторю свой тезис - нужно четко разделять возможности железа и OS.

Я думаю что это разные вещи. 2-way, 4-way не увеличивает размер (диапазон) адресуемой памяти. Они делают доступным команде процессора несколько адрессных пространств, каждое в рамках обычного диапазона адресов. Например в случае 2-way командой процессора MVCS (Move to Secondary), или MVCP (Move to Primary) можно мувать данные из одного адресс спэйса в другое. Называются эти пары связанных АS, как уже понятно, Primary и Secondary. В случае с 4-way появляются еще большие возможности подобного плана, но там все сложнее и там еще добавляются аппаратные регистры процессора - Access Registers - и нам лучше в те дебри не лезть. Выбраться не сможем в рамках форума. Но идея примерно та же как и с 2-way.

Dmitry67 · Post by **Dmitry67** » 22 Jun 2007 17:04

А зачем это?
Ядро все равно все что угодно куда угодно переместить может
А пользовательскому процессу много адресных пространств - зло

Palych · Post by **Palych** » 22 Jun 2007 17:05

Brazen wrote:
zVlad wrote:Другой разделяемой областью виртуальной памяти в адрессных пространствах приложений является ядро системы (nucleus). В адресном пространстве каждого приложения в определенных адресах представленно ядро системы.

Ну и нахрена? Тем более, что его нельзя изменять. Ядро -- это черный ящик, передал аргументы, получил результат. Что там в ядре, программу не должно интересовать. Соответственно, и распределять ядро на память программы смысла не имеет.

Допустим на МФ бегает 2 виртуальных Линукса.
Как я понимаю - они могут шарить образ ядра, правильно?
А ну как понадобилось в одном из ВЛ загрузить драйвер (SuperPuperFS module). Соответственно он не должен быть доступен никому более.
Возможно ли такое?

zVlad · Post by **zVlad** » 22 Jun 2007 17:09

Dmitry67 wrote:....
Думаю, сертифицировать на чтото систему, где OS видна в памяти процесса, даж RO, тяжело
Если только там никогда не появляются данные ОС

Почему это интересно Вы так думаете? Любому пользователю ОС доступен код этой ОС ядра и его можно "посмотреть". Тем не менее это еще ни одной ОС не помешало сертифицироваться.

Данные данным рознь. Данные системы созданные для обслуживания данного приложения этому приложению доступны в этого приложения адресном пространстве. Данные других приложений находятся в из пространствах и другим приложения естественно не доступны. Имеются однако общесистемные данные которые доступны всем приложениям. Но можете не сомневаться Дима доступность этих данных не делает систему сколько-либо уязвимой.
У меня, например, есть программка которая выполняется каждый раз когда я вхожу с систему. Эта програмка "пробегается" по системным блокам данных и "докладывает" мне разные, кажные для меня данные. Это примерно так выглядит:

Code: Select all

  *** z/OS 01.07.00 - JES2 1.7 - DFSMS/MVS 1.07 - RACF 7720 - VTAM 6.1
  *** SYSRES=ZOSRES(61C3) - IODFDEV=63C5 - LOADxx=LOAD00
  *** SYSPLEX=LOCAL - SYSNAME=MVS0EA - NODE=N6 - CLPA=YES
  *** Today's date is June 22, 2007
  *** System IPLed on March 11, 2007 and has been up 103 days

 *** ASVT
 *** ASVTAAV(MAXUSER) =  500 with 368 free slots.
 *** ASVTANR(RSVNONR) =  500 with 429 free slots.
 *** ASVTSTR(RSVSTRT) =  5 with 5 free slots.
 *** ASVTMAXU(total)  =  1005

Flash-04 · Post by **Flash-04** » 22 Jun 2007 17:18

Dmitry67 wrote:На самом деле так в VAX/VMS тоже было сделано
Там в старших 2Gb виднелась read-only система и всякие библиотеки
Сами EXE получались маленькие и разделяли эти библиотеки
Думаю, сертифицировать на чтото систему, где OS видна в памяти процесса, даж RO, тяжело
Если только там никогда не появляются данные ОС

так и в Windows то же самое, верхние 2Gb - это R/O системные DLL и прочее. Внутренность ядра тем не менее не видна наружу.

zVlad · Post by **zVlad** » 22 Jun 2007 17:24

Dmitry67 wrote:А зачем это?
Ядро все равно все что угодно куда угодно переместить может
А пользовательскому процессу много адресных пространств - зло

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

Поверьте Дима то что сделано на МФ - это сделано со смыслом, и я думаю что если Интел действительно развивается в сферу полноценных МП/МЗ/В установок, то и у него что-нибудь подобное появится должно.

Dmitry67 · Post by **Dmitry67** » 22 Jun 2007 17:41

Хм, насколько я понимаю, ядро, так как обладает абсолютными правами, может смастерить себе произвольное адресное пространство, захватывающее произвольные куски памяти, принадлежащих произвольным процессам. Наверное, часть этого адресного пространства включает в себя ядро и никогда не меняется (а не называется ли это "Non-paged memory"?), а часть может меняться как ему, ядру, нужно. Во всяком случае я так себе это представлял

zVlad · Post by **zVlad** » 22 Jun 2007 18:46

Palych wrote:
Brazen wrote:
zVlad wrote:Другой разделяемой областью виртуальной памяти в адрессных пространствах приложений является ядро системы (nucleus). В адресном пространстве каждого приложения в определенных адресах представленно ядро системы.

Ну и нахрена? Тем более, что его нельзя изменять. Ядро -- это черный ящик, передал аргументы, получил результат. Что там в ядре, программу не должно интересовать. Соответственно, и распределять ядро на память программы смысла не имеет.

Допустим на МФ бегает 2 виртуальных Линукса.
Как я понимаю - они могут шарить образ ядра, правильно?
А ну как понадобилось в одном из ВЛ загрузить драйвер (SuperPuperFS module). Соответственно он не должен быть доступен никому более.
Возможно ли такое?

Вообще говоря я имел в виду структуру памяти в z/OS. Принцип работы z/OS таков что каждое приложение "видит" себя и ядро как если бы это было единственное приложение в системе и никаких других приложений не было бы. И так каждое приложение.
В VM, каждая ВМ "видит" память ВМ от адреса 0 до максимального и вправе использовать любой адрес как угодно, вся память от 0 до максимума доступна и для чтения и для записи. ОС ВМ сожет иметь разделяемые с другими аналогичными ОС ВМ области памяти, это во-первых должно быть задано внешним по отношению к ВМ образом, а именно в описании хр. системы, и во-вторых не запрещает ОС ВМ модифицировать саму себя в точ числе в описаных как разделяемые областях памяти. Просто СР создаст тогда уже индивидуальную копию памяти такой ВМ. Кстати, вспомнил, есть еще одно интересное обстоятельство в VM. Разделяемые сегменты обычно помещаются в области с достаточно большими адресами, выше максимального адреса памяти ВМ. Иными словами предположим мы дали ВМ 10 МВ памяти, при этом разделяемый сегмент хр.системы находится в области памяти начиная с 14 МВ. Строго говоря память начиная с 14 МВ ВМ-е не доступна, но программы в этих адресах выполняться могут. Так вот если мы увеличиваем размер памяти ВМ "на ходу" (такая возможность есть в VM) и делаем ее скажем 16 МВ, тогда СР создаст такой ВМ ее собственню копию разделяемого сегмента и ОС ВМ получит возможность модифицировать эту память.

Brazen · Post by **Brazen** » 22 Jun 2007 19:06

zVlad wrote:Я думаю что это разные вещи. 2-way, 4-way не увеличивает размер (диапазон) адресуемой памяти. Они делают доступным команде процессора несколько адрессных пространств, каждое в рамках обычного диапазона адресов. Например в случае 2-way командой процессора MVCS (Move to Secondary), или MVCP (Move to Primary) можно мувать данные из одного адресс спэйса в другое. Называются эти пары связанных АS, как уже понятно, Primary и Secondary.

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

zVlad wrote:Эта програмка "пробегается" по системным блокам данных и "докладывает" мне разные, кажные для меня данные. Это примерно так выглядит

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

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

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

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

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

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

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