Here be dragons: Управление памятью в Windows как оно есть [1/3]

хотелось бы увидеть что нибудь вроде этого
geekswithblogs.net/akraus1/archive/2009/10/04/135294.aspx

думаю, тоже будет сильно интересно:)

Потому, что назначение свопа компенсировать недостаток ОЗУ, а не забивать свободную память.

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

Согласен с Мицголом, надо написать топик. В рамках недели просвещения на Хабре.

О таком сценарии не подумал — действительно имеет место быть. Добавил в апдейты

Либо я чего-то не понял, либо Вы тоже заблуждаетесь. Та память, которую «не видно» — это memory mapped I/O и области для доступа к видеокарте например, к ее памяти через адресное пространство оперативной. Так или иначе, эти адреса недоступны физически на уровне PCI-мостов, никакими ухищрениями с пейджингом увидеть их не получится. Это тот случай, когда памяти ровно 4 гига. Если памяти больше, скажем 8 гигов, тогда можно написать свой драйвер RAM-disk-а, который сможет использовать память выше 4 гигов (то что между 3,3 и 4 увидеть все-равно не получится) но смысла в этом никакого, тут надо ставить x64.
У современных чипсетов есть такая фича — memory remap feature, которая позволяет отмапить часть оперативки в пространство выше 4Gb, на первый взгляд кажется, что это то что нужно, пишем свой драйвер, работающий с этой памятью и размещаем своп там, выше 4 гигов. На практике это опять же лишено всякого смысла, потому что для доступа к этой памяти нужен диапазон адресов в первых 4-х гигах, которые придется попросить из системного адресного пространства и вручную поправить таблицы страниц, но мы при этом забираем у системы виртуальные адреса, которые ей возможно нужнее, чем дополнительный своп, можно конечно каждый раз выделять/освобождать при каждом обращении к этому «свопу», но в этом еще меньше смысла.
В общем я бы сказал так, теоретически при наличии должной поддержки со стороны желаза и в каком-то особом случае, когда известно что можно безболезненно забрать у системы часть системного виртуального адресного пространства, это может и принесет какую-то пользу, но всем и каждому я бы это не рекомендовал. Это примерно как кошке пятая нога иногда может быть полезна. Поправьте меня.

Позвольте с вами не согласиться!
Включенный режим PAE позволяет 32-битной операционной системе эффективно использовать доступную физическую память далеко за пределами 4 ГБ (вплоть до 64 ГБ).
Конечно же, виртуальное адресное пространство одного конкретного процесса останется неизменным. Но при этом физическая страница ОЗУ, соответствующая какой-либо странице виртуальной памяти, может лежать за пределами 4 ГБ.
Я не буду вдаваться в подробности, все уже расписано до меня, почитайте, интересно: http://en.wikipedia.org/wiki/Physical_Address_Extension
Зная этот факт, я бы не стал утверждать, что pagefile в RAM-диске — это выгодно. А вы проверяли? Делали какие-нибудь тесты?

Кстати, неправильно говорить, что 32-битное приложение не может использовать больше 4 ГБ ОЗУ;) На windows это делается посредством AWE: http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx
Сомневающимся настоятельно рекомендую написать простенькую программку своими руками. Это очень занимательно:)

4 гига и до сих пор на XP x86. Мсье знает толк в извращениях :-)

У меня тоже чисто практический опыт. До хрома я пользовался оперой что то около восьми лет. В рамках программы по легализации всего и вся, я стал слушать музыку с пандоры, ласт.фм и имеем при этом никогда не перегружаясь без острой необходимости (апдейты и пр). Не знаю, был ли это лик или флеш так кеширует, но опера достаточно быстро вырастала за гигабайт. Причем система использовалась достаточно активно (виртуалки, большие проекты в VS, всякий дотнетовский lob и пр.) — тормозов не наблюдалось.

Здесь как в теории так и на практике есть некоторый «конфликт интересов»: система пытается не вырезать Working Set-ы и скорее выбросит кеш, так что повершеловский скрипт, который я привел, может ИНОГДА помочь вручную сбросить «утекшую память» сначала в modified список, а потом и в пейджфайл. Но на практике, я этого никогда не делал и никогда не имел проблем с производительностью (в смысле по причине нехватки памяти)

In use — это вроде как Working Set всех приложений. Stend by и modified — помеченные для освобождения страницы. В принципе, в modified могут быть и измененные проекции файлов, открытых для записи. Но мне почему-то кажется, что проекции редко делают для записи, и в основном это могут быть какие-нибудь торренты, которые все равно хеши от частей файлов считают.

Да, то что приложения использую прямо сейчас — это In Use. Если приложение получило физическую страницу в свой рабочий набор, но после того как эта страница была «подрезана», в случае приватных данных она попадает в Modified список с «намерением» сбросить ее в pagefile. В этом списке ее можно держать сколь угодно долго — это данные могут быть потеряны только вместе с единственным процессом, который может их использовать

Хм, я тоже совершенно не представляю, как они это делали :-)
По моим нынешним представлениями, как я уже сказал, невозможно взять у системы физическую память так, чтобы она не отобразилась в Working Set. Вполне допускаю, что я чего не знаю, но сильно подозреваю, что здесь что то другое, чего автор просто не учел: к примеру, какой то драйвер (наподобие обсуждаемого там же eboostr) кешировал файлы для оперы и делал это в non paged pool. Это должно было бы быть видно на Task Manager-овском Performance Tab-е.

Кстати, еще интересно было бы узнать, менялся ли commit limit (когда кто-то выделяет non-paged pool — это не увеличивает commit charge, а уменьшает commit limit). В общем скриншот Process Explorer-овского system info мог бы помочь при выяснении причин