архитектура памяти Windows

пожалуйста, помогите разобраться, тема для меня крайне сложная, но при этом важная:

- цитата из книги Рихтера, не могу никак понять как используемый термин "физическая память" соотносится с данными на жестком диске, до этого момента воспринимал их как одно и то же... но тут запутался...

 

Файл подкачки страниц памяти появился в те времена когда 4Гб оперативки адресуемые в 32битном режиме были даже не несбыточной мечтой а научной фантастикой - даже на диске эти 4Гб появились несколько позже
А памяти всегда хотелось больше чем её есть на самом деле
Поэтому и был реализован полностью прозрачный для юзермодного программера механизм подкачки страниц памяти с диска. Т.е. программы могут обращаться с памятью так как будто её столько сколько позволяет файл подкачки а не столько сколько есть реального ОЗУ и проявится это только в притормаживании из-за обращений к диску

 

ой брееееееед)

 

=) за исторический экскурс, спасибо, дело в том что это понятно, но конкретно по цитате... не понимаю что автор имел в виду говоря "физическая память" если не сами данные на ЖД?

 

Great =) была надежда на твою реакцию и вразумительный ответ=) совсем запутался... но так действительно написано в книге, можешь хоть как то разъяснить ситуацию? о чем речь идет?

 

Vic
ОН тебе не поможет с таким вопросом. Вначале тут прочитай:
http://www.wasm.ru/article.php?article=mem_management

 

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

 

Ясен йух, зачем тогда форум?

 

И что здесь непонятного или бредового?
Если бы файла подкачки не было, то для программы физическая память (и соответственно её размер) была бы только та, что находится в микросхемах. Но так как файл подкачки есть, то с точки зрения системы "физическая память" на самом деле это файл подкачки, у которого ОЗУ выполняет роль КЭШа. А с точки зрения юзермодной программы (которая не видит механизма подкачки) эта попрежнему "обычная физическая память" только большего размера

"Физическая память" это вообще-то как раз та память что в микросхемах ОЗУ, она тоже имеет страницы, которые ось раскидывает по требуемым адресам в прикладных программах. Но кроме этого ось совершает "подтасовку" подменяя настоящие страницы памяти, страницами с ЖД (а это уже вообще-то не одно и тоже но поскольку прикладная программа об этом не знает, то для неё такие "фальшивые" страницы по прежнему физическая память

 

Y_Mur,
так правильно ли я понял, что для юзермодной программы физическая память представляется как ОЗУ большого объема, хотя на самом деле это файл подкачки + действительный размер ОЗУ??

 

Если уж быть точным, программы пользовательского режима работают исключительно с виртуальной (воображаемой) памятью, и называть её физической совершенно некорректно. Физическая память -- та, что реально имеется на компутере (которая обеспечивается микросхемами памяти), виртуальная же создаётся осью путём использования файла подкачки на диске и имеющейся физической памяти. Причём у каждой программы пользовательского режима виртуальная память своя, отдельная от других программ, хотя и файл подкачки, и физическая память, есно, общие. За такое разделение отвечает ось.

 

все теперь понятно, господа , спасибо всем за помощь и разъяснения, особенно Y_Mur и SII =)

 

Ну а если уж быть совсем точным, то в win32 каждая прикладная программа имеет виртуальную (воображаемую) память размером 4Гб (правда использовать она имеет право не всё, а только 2 или 3Гб но это не важно
Если запущено одновременно 25 программ то они имеют полное право "вообразить" что машина имеет память 100Гб )
Понятно что в реальности им никто столько не даст, да оно им не нужно

Когда программа заявляет что ей нужна виртульная память (VirtualAlloc с флагом MEM_RESERVE) то она получает всего лишь право использовать выделенный ей в ответ диапазон адресов (в пределах тех самых 4Гб) - но реальной "физической памяти" в этом диапазоне адресов ещё нету Такая заявка всего лишь гарантия того, что этот диапазон адресов не окажется занятым осью (обрати внимание осью, а не другой прикладной программой имеющей свои персональные воображаемые 4Гб).

А вот когда программа вызывает VirtualAlloc с флагом MEM_COMMIT тогда уже по указанному програмером или выделенному осью адресу появляется настоящая "физическую память" т.е. часть воображаемой памяти становится реальной (физической), причём воображаемое пространство не обязано заполняться последовательно, куски физической памяти можно втыкать в него как попало.
Это уже настоящее ОЗУ взятое из микросхем памяти.
Но если его на всех не хватает, то ось имеет полное право по своему усмотрению временно сохранить некоторые страницы памяти в файле подкачки и отдать эти страницы "настоящей физической памяти" тому кто в ней нуждается, а когда информация которая была в этих "украденных осью" страницах опять понадобится, то они опять будут считаны с ЖД, не обязательно в те же страницы ОЗУ где эта информация была до сохранения, а затем ось спроецирует эти новые страницы настоящей физической памяти, но со старой информацией на то место виртуального адресного пространства, где эта информация был до "похищения памяти", и юзермодная программа этого не заметит

 

все это приходит месяцами, а то и годами. дальше больше, столкнетесь с десятками вопросов, по типу, какая память на какую проецируется - физическая на виртуальную или наоборот и почему, а ведь в книгах пишут то так то эдак. Имхо к рихтеру надо прислушатся и помедитировать над его текстами. Мне для того чтобы в башке все лучше улажилось нужно вычитывать или выдумать подходящие определения, например вот это распространенное определение про виртуальную память, мол представляет собой озу + винт, имхо если винта не будет, память не перестанет быть виртуальной для программ. мне нравится такое: виртуальная память - это диапазон чисел(адресов), которыми оперируют программы (опред. неполное). Как только я первый раз столкнулся с термином проецирование я подумал что физическая память есть некоторая сущность, а виртуальная - набор адресов, поэтому посчитал что физические страницы проецируются на виртуальные, но теперь придерживаюсь обратного, так как всем известно что программы для адресации могут использовать только вирт. адреса. Посколько я только учусь мог недоговорить или наврать, был бы рад если б кто направил на путь истинный

 

Я бы еще посоветовал помедитировать над книгой Руссиновича и Соломона.

 

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

 

Y_Mur

Важно-важно. В Вашем посте наблюдается некоторое... э... смешение понятий, так скажем.

В частности, никакая прикладная программа в win32 не имеет виртуальной памяти размером 4 Гб -- она имеет виртуальное адресное пространство такого объёма. Любая программа может сформировать виртуальный адрес от 0 до FFFFFFFF включительно, однако обратиться сможет только по тем адресам, которым соответствует выделенная ей виртуальная память. Причём, заметим, размер виртуального адресного пространства зависит от архитектуры процессора (для IA-32, если не используется сегментация, он будет составлять 4 Гб в любой 32-разрядной системе -- хоть в Винде, хоть в Линухе, хоть в Солярисе каком), а вот максимальный размер виртуальной памяти, доступной для задачи -- не только от архитектуры процессора, но и от архитектуры оси. Например, в 32-разрядной Винде в зависимости от её версии и параметров предельный объём виртуальной памяти задачи составляет 2 или 3 Гб (без 4 Кб, насколько помню), поскольку из 4-Гб виртуального адресного пространства старший гигабайт или два зарезервированы для нужд самой оси.

Для такой ситуации можно было бы говорить о 100 Гб виртуального адресного пространства, но не виртуальной памяти -- последней будет меньше. Например, в обычной ХРюше, даже если каждой программе будет выделено по 2 Гб виртуальной памяти и плюс 2 Гб будет занимать сама ось, получим в сумме 52 Гб.

Ось по-любому не займёт виртуальную память, лежащую вне отведённого для неё фиксированного диапазона виртуальных адресов (т.е. старших 1-2 Гб).

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

defaultplayer

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

 

defaultplayer

ИМХО, будет ошибочным. Виртуальная память отображается на физическую память и файл подкачки, а не наоборот.

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

 

SII

Да пожалуй ты прав не стоит смешивать эти термины.

Имелось в виду, что АПИ тоже часть оси, а они запросто берут юзермодную память, конечно же используя её для нужд той юземодной программы у которй взяли, но программер должен быть готов к ситуации, что в его виртуальном адресном пространстве вдруг могут появиться блоки памяти которые он явно не выделял и соответсвенно не может самостоятельно освбодить для контроля над этим как раз MEM_RESERVE

Проверил, действительно ты прав выделение большого блока с MEM_COMMIT не приводит к интенсивному перемесиванию файла подкачки, значит физическая память выделяется не сразу, а только по мере реальных обращений к соответствующим страницам.
Собственно хотел подчеркнуть, что физическая память к которой обращается программа всегда реальная та что в ОЗУ, а вот информация из неё может временно и "незаметно" храниться в файле подкачки

ЗЫ: На счёт того что память занятая под код системы расходуется только один раз конечно согласен, но имхо для "фантазирования" это не принципиально ;

 

сейчас я уже тоже так считаю, и тоже считаю это верным

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