Низкая производительность совместно используемой памяти при переходе на 64-битную ОС - PullRequest
Новая
       35

Низкая производительность совместно используемой памяти при переходе на 64-битную ОС

2 голосов
/ 03 сентября 2010

У меня проблема с 32-разрядным устаревшим приложением, работающим в 64-разрядных окнах. Рассматриваемое приложение использует CreateFileMapping для создания общей памяти. Когда это выполняется в 64-битной Windows, любая попытка доступа к этой общей памяти из другого процесса занимает около 1 секунды. Общая память создается с использованием флагов защиты страниц: 

flProtect = PAGE_READONLY | SEC_NOCACHE | SEC_COMMIT;

при создании той же памяти с помощью: 

flProtect = PAGE_READONLY | SEC_COMMIT;

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

Может кто-нибудь объяснить мне, почему SEC_NOCACHE повлияет на производительность в этой ситуации?

Обновление: похоже, что только запись в этот буфер увеличилась до 1000 мс. Чтение, похоже, не влияет. За это время мы записываем в буфер около 5 МБ.

Обновление 2: Это программное обеспечение используется во многих системах, и одна из систем имеет физическое устройство, которое требует использования этого флага. В настоящее время мы работаем с этим устройством в 32-битных окнах.

Ответы [ 3 ]

3 голосов
/ 03 сентября 2010

Вот что Microsoft должен сказать об этом флаге:

Флаг SEC_NOCACHE предназначен для архитектур, которым требуется, чтобы в памяти находились различные структуры блокировки, которые никогда не извлекаютсяв кеш процессора.На компьютерах с архитектурой x86 и MIPS использование этого флага только снижает производительность, поскольку аппаратное обеспечение сохраняет согласованность кэша.

К сожалению, они не определяют количество замедления.

1 голос
/ 03 сентября 2010

Вы отключаете кеш файловой системы с этим флагом.Да, это имеет огромное значение , заставляет ОС работать с драйвером диска и напрямую читать сектора.Цилиндры не могут быть прочитаны и кэшированы, отключив оптимизацию, которая делает чтение дорожек без необходимости перемещать считывающую головку так дешево.И отложенная обратная запись отключена, оптимизация, которая делает запись на диск, появляется мгновенно.

0 голосов
/ 03 сентября 2010

Я думаю, что из-за того, что память должна быть переназначена с 64-битной на 32-битную, создание буфера 'bounce' обходится дорого.Когда кэширование включено, этот буфер восстановления неявен, и ОС может обойти необходимость постоянного обновления раздела памяти.

...