Здравствуйте, уважаемые подписчики.

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

Надеюсь, что даже те, кто не использует Windows NT4, найдут в выпуске что-то
интересное для себя.

Параметр SecondLevelDataCache в Windows NT4

В 25 выпуске (www.redline.ru/~ipl/jun99.htm) я, базируясь на информации,
полученной от сотрудника "Майкрософт", связанного с разработкой этой операционной
системы, постарался показать ошибочность данного утверждения.

Тем не менее, некоторое время назад достоверность моей информации была
поставлена под сомнение. При этом ссылались на статью Q183063 в базе знаний
"Майкрософт".

Разница действительно есть, и на первый взгляд, довольно большая. На самом деле
наиболее существенным является расхождение в том, должно ли значение параметра
указываться в байтах или в килобайтах.

Я обратился к "Яндексу" и был просто ошарашен результатами. Из более чем
семидесяти найденных в рунете ссылок все, кроме одной (угадайте, какой), дружно
утверждали, что NT не умеет сама полностью использовать кэш-память процессора
второго уровня и ее величину обязательно надо задавать в реестре. Более щедрые
товарищи обещали прирост производительности от 8 до 20 процентов, те, кто
поскромнее - от трех до пяти процентов.

Несколько обескураженный, я предпринял такой же поиск в базах MS.
Отыскались 12 ссылок, отчасти повторявших друг друга. Основные версии были
таковы.

Во-первых, уже упомянутая статья в базе знаний (о ней речь пойдет ниже), в
которой ясно сказано, что она применима только к NT4. Во-вторых, в Windows 2000
Resource Kit имеется краткое упоминание о том, что в Windows 2000 этот параметр
задавать нельзя. Что, несмотря на ошибочную информацию, поступающую из других
источников, его изменение не даст прироста производительности. Windows 2000 сама
определяет размер кэш-памяти второго уровня и использует ее полностью независимо
от значения данного параметра.

Еще один вариант утверждал, что НТ обращается к этому параметру только в тех
случаях, когда не может сама определить размер кэша. Параметр может дать выигрыш,
но использовать его надо осторожно, поскольку при неправильном указании размера
кэша стабильность системы может нарушиться (этот совет находился в разделе,
посвященном Windows NT Advanced Server, а я сильно сомневаюсь, что сейчас он
установлен хоть у кого-нибудь).

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

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

Вопрос-ответ

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

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

     * Если вы используете процессор новее, чем первый вариант "пентиума"
(максимальная тактовая частота 200 МГц), оборудование само предоставляет
правильную информацию о размере кэш-памяти второго уровня и вы НЕ ДОЛЖНЫ задавать
этот параметр в реестре (и статья, и мое сообщение в этом отношении согласуются
друг с другом).

Другие комментарии я поместил в соответствующие места статьи.

"Игорь Лейко (Igor Leiko)" <ipigl@redline.ru> написал
> Джон,
> три года назад вы отправляли сообщение о параметре
> SecondLevelDataCache. Вот отрывки из него (к сожалению,
> сообщение целиком у меня не сохранилось).
>
> "Этот параметр был использован для экспериментов с тонкой
> настройкой некоторых внутренних структур данных диспетчера
> программ, чтобы оптимизировать работу кэш-памяти второго
> уровня".
> "Его значением должен быть размер кэш-памяти второго уровня
> в байтах. Не в килобайтах, не в мегабайтах, а в обычных
> байтах. Первое, что мы делаем с этим значением – сдвигаем
> его на 12 битов вправо и используем в дальнейших
> вычислениях полученное число. Если после сдвига вправо
> мы получаем ноль, то используем некоторое значение, принятое
> по умолчанию (то же, что и в случае, когда параметр равен
> нулю). Поэтому поставите ли вы значением параметра число 256
> или число 512, все равно после сдвига получите ноль".
>
> Но статья Q183063 дает другое объяснение (далее – текст статьи).
> "HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet\Control\Session
> Manager\Memory Management\SecondLevelDataCache
> тип: двойное слово, размерность: килобайты, значение – размер
> кэша. По умолчанию: 0 (256K)
>
> Параметр SecondLevelDataCache записывает размер кэш-памяти
> процессора, называемой также вторичным кэшем или кэшем второго
> уровня. Если значение этого параметра равно нулю, система
> пытается получить размер кэша второго уровня от модуля HAL.
> Если значение параметра равно нулю, она использует значение
> 256 КБ. Если значение параметра не равно нулю, в качестве
> размера кэша используется указанное значение. Параметр
> разработан как вторичный источник информации о размере кэша
> второго уровня для компьютеров, на которых модуль HAL не
> может его определить”.

Обратите внимание на две вещи:

а) система _получает_ размер кэша второго уровня, а не _устанавливает_
его. Другими словами, весь кэш включается и используется аппаратно, и Windows не
может на это повлиять. Проведем не совсем корректную аналогию с автомобилем:
чтобы узнать мощность двигателя, вы читаете документацию к автомобилю. Теперь вы
знаете, какова она. Но, что бы ни было там написано, это абсолютно не повлияет на
мощность того двигателя, который фактически установлен в машине;

б) гораздо более важно следующее: для всех современных микропроцессоров
надлежащее значение – 0 (или отсутствие параметра), и нужная величина будет
установлена автоматически.

> "Это не связано с оборудованием и дает эффект лишь на
> компьютерах с кэшем второго уровня, непосредственно
> отображаемым в память. Пентиум II и более поздние процессоры
> не имеют такого кэша".

ВАЖНОЕ ЗАМЕЧАНИЕ: для Пентиум II и более поздних процессоров не имеет
значения, как устанавливается данный параметр; в них нет того типа кэша, который
мог бы использовать данный параметр.

> "SecondLevelDataCache может увеличить производительность
> приблизительно на два процента в отдельных случаях для
> старых компьютеров с большим объемом памяти (больше 64 МБ)
> за счет лучшего распределения физических страниц в адресном
> пространстве, приводящего к уменьшению числа коллизий
> в кэше второго уровня".

Обратите внимание, на что именно влияет этот параметр: не на то, используется
ли кэш второго уровня, и не на то, насколько он используется. Изменяется только
алгоритм распределения физических страниц в адресном пространстве, чтобы
уменьшить число коллизий в КЭШЕ С ПРЯМЫМ ОТОБРАЖЕНИЕМ В ПАМЯТЬ, ИСПОЛЬЗУЕМЫМ В
ОРИГИНАЛЬНОМ ПРОЦЕССОРЕ ПЕНТИУМ.

> "Установка значения параметра SecondLevelDataCache равным
> 256 КБ вместо 2 МБ (если компьютер имеет кэш второго уровня
> размером 2 МБ), возможно, дала бы снижение производительности
> примерно на 0,4 процента".

Я сомневаюсь, что вы смогли бы измерить такое изменение, и, безусловно, вы не
сможете его заметить. Поэтому, даже установив неправильное значение, вы не
увидите никаких изменений в производительности.
 

Рассуждения

Во-первых, если и имеет смысл задавать этот параметр, то только в NT4, но не в
Win2000.

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

Пентиум Про относится к тому же семейству, что и Пентиум II, и он также умеет
сообщать размер кэш-памяти второго уровня. Об этом, в частности, прямо говорил
разработчик, чье письмо я цитировал в двадцать пятом выпуске.

Остается неясной ситуация с тремя моделями первого семейства Пентиум. Их
именно три – первоначальный вариант, более современная модель с частотами до 200
МГц и Пентиум ММХ. По крайней мере одна из моделей, а, скорее всего, все три не
умеют сообщать системе размер кэш-памяти второго уровня. Это вовсе не означает,
что НТ не может использовать кэш полностью. Кэш-память используется не
операционной системой, а самим процессором, она управляется контроллером
кэш-памяти, который для указанных моделей находится на системной плате. Просто НТ
не может оптимально организовать назначение физических страниц страницам
виртуальной памяти.

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

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

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

Для некоторых компьютеров говорится о возможности двухпроцентного прироста
производительности, чуть позже говорится, причем в сослагательном наклонении, о
выигрыше (или, наоборот, проигрыше при неправильном задании параметра) в 0,4
процента.

После некоторых раздумий я пришел к следующему выводу. Упоминание о
_некоторых_ компьютерах с памятью свыше 64 МБ наверняка не случайно. Сопоставим
его с тем общеизвестным фактом, что у наборов микросхем 430TX и 430VX
(предназначенных как раз для процессоров семейства Пентиум I) кэш-память второго
уровня кэширует только первые 64 МБ физической памяти. В обзорах тех лет
неоднократно упоминалось, что Windows 9x в компьютерах, использовавших эти
наборы, на 80 МБ ОЗУ работала медленнее, чем на 64 МБ. Это было связано с тем,
что ядро системы попадало в некэшируемую область и обращение к нему заметно
замедлялось.

Судя по всему, Windows NT умела помещать часто используемые данные в
кэшируемую область памяти. И чем больше был размер кэш-памяти, тем больше данных
эффективно кэшировались. В этом случае правильное указание размера кэш-памяти
обеспечивало более эффективное кэширование по сравнению с ситуацией, когда
предполагался размер кэша в 256 КБ.

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

А откуда же взялись упоминания о 8-20 процентах выигрыша? Об этом надо
спросить у тех, кто такие советы давал. Могу предположить, что люди рассуждали
вполне логично (но исходя из неправильных предпосылок). Если замена процессора с
кэш-памятью 256 КБ таким же, но с кэшем 0,5-2 МБ дает от 8 до 20 процентов
выигрыша в производительности, то и использование полного объема кэша вместо 256
КБ дает такой же выигрыш.

Теперь то же самое, но вкратце:
 

Выводы

Если у вас установлена Windows 2000 или Windows XP, не изменяйте этот
параметр. Впрочем, проигрыш, скоре всего, также окажется незаметным.

Если у вас установлена Windows NT4 и процессор семейства Пентиум I, то
установка правильного значения кэш-памяти может дать выигрыш от одной-двух
десятых процента до двух процентов, то есть практически разницы вы не ощутите.

Байты или килобайты

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

Дополнительным доказательством служит тот факт, что в том же разделе
"Evaluating Memory and Cache Usage" документа "W2000 Resource kit", в котором
идет речь об обсуждаемом нами параметре, упоминается об установке значения
параметра PagedPoolSize равным 192000000, что ограничивает размер этого пула 192
МБ. Налицо путаница в мегабайтах и миллионах байтов, но нет никакого сомнения,
что значение указано именно в байтах, а не в килобайтах.

Оно вам надо?

Хотите повысить свою квалификацию и честно писать в резюме о знакомстве с
продуктами Oracle? Компания предлагает вам бесплатно две недели пользоваться
через веб-интерфейс ее продуктом: "Oracle Small Business Suite FREE Trial:
Integrated accounting, payroll, crm, expense reporting and more". Вот ссылка.

http://www.redline.ru/~ipl