OSDev

Интересует такой вопрос. Если я на голом железе (x86_64), без операционной системы, выполняю чтение с жёсткого диска одного сектора в оперативную память. Чтение выполняет контроллер DMA, предположим что чтение выполняется не первый раз. То есть при предыдущем доступе к прочитанному сектору, процессор поместил в кэш эту область памяти. Так как процессор после этого к этой области памяти не получал доступ, а контроллер DMA обновил там информацию, то наверное, нужно выполнить команду INVLPG <адрес> (недостоверность элемента буфера TLB). Экспериментировать сложно, может кто знает, как правильно действовать?

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

Что же касается обмена с устройствами по DMA, то, в общем-то, да. Перед тем, как выполнять запись на устройство, нужно обеспечить, чтобы данные из кэша процессора были уже записаны в физическую оперативную память (кэши часто работают в режиме с обратной записью -- Write Back, -- при которой не спешат переписывать изменённую информацию в ОЗУ; кэши со сквозной записью -- Write Through -- делают такую запись сразу, но работают из-за этого менее эффективно). После чтения с устройства надо аннулировать в кэше элементы, соответствующие прочитанным адресам. Вот как это делается на ПК, я не помню от слова совсем -- под них писал последний раз с четверть века назад.

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

Полистал руководство по архитектуре. В общем, после сброса работа кэшей запрещена (бит CD в CR0 установлен). Пока сей бит не будет сброшен, кэши не работают, а соответственно, и проблем с согласованностью содержимого памяти при использовании DMA не будет. Если же включить кэш, там уже надо самостоятельно заботиться об этих вещах (можно, например, запретить кэширование конкретных областей и использовать для ввода-вывода именно их; можно перед записью с помощью DMA принудительно сбрасывать изменённые строки кэша в память, а после чтения с помощью DMA -- принудительно аннулировать строки). Всё это описывается в 11-й главе 3-го тома, "Memory Cache Control".

Большое спасибо за ответ. Эксперимент делать сложно и не хочется, вот поэтому решил спросить. Буду разбираться

Начал изучать кэширование, может тороплюсь поделится, но похоже что с точки зрения здравого смысла, так должно работать. Далее цитата из Гук.М, Юров В. "Процессоры Pentium 4, Athlon и Duron" стр. 165 : "Кэш-памяти процессоров строится с учётом возможности обращений к памяти со стороны внешних абонентов - других процессоров или иных контроллеров шины. ... процессор определяет присутствие затребованной области в своём собственном кэше. ... Обращение по записи (внешнего абонента к памяти пр-е моё), вызовет аннулирование данной строки. Обращение по чтению к области, соответствующей модифицированной (грязной) строке, вызовет выгрузку её содержимого в основную память, прежде чем внешний абонент выполнит реальное считывание." Так что похоже ни каких телодвижений не нужно, за исключением, изменения таблиц трансляции. Если ещё что то накопаю, напишу.

Не исключено. Что процессоры поддерживают свои кэши согласованными друг с другом, я знаю (и это напрочь убивает возможность масштабирования серверов, ведь для этого нужна быстрая связь "все со всеми"). А вот насчёт отслеживания доступов периферии -- не помню (а может, и не знал никогда).

Кстати, о здравом смысле и всём таком прочем

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

По этой причине во многих архитектурах аппаратного поддержания согласованности кэшей нет или оно ограничено некими пределами. Скажем, на IBMовских мэйнфреймах (хоть на древней Системе 360, появившейся в середине 1960-х, хоть на её далёких потомках в лице современной z/Architecture) процессор "замечает" запись в кэш только со стороны самого себя: если используется самомодифицирующийся код, никаких телодвижений предпринимать не нужно. Но он "не видит" записи ни со стороны других процессоров, ни со стороны ввода-вывода; соответственно, об этом нужно помнить программисту. (Впрочем, там это, как правило, несложно: любое прерывание вызывает так называемую сериализацию, т.е. завершение выполнения всех уже начатых команд, полную запись изменённых строк кэшей в память и аннулирование кэшей, и лишь после этого начинается выполнение обработчика прерывания -- соответственно, любые изменения в памяти, внесённые на момент прерывания, воспринимаются автоматически.) А, например, ARMы имеют право не видеть самомодификацию кода, т.е. там для гарантии, что модификация будет замечена, надо использовать так называемые барьеры данных и команд.

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