работа с I/O-memory

> Нужно ли при записи регистров использовать msync

нет, не нужно.

Что ж ты про барьеры не написал? :)

На i386 по идее драйвер может поставить области UC атрибут, но вроде как этого многие не делают, да и не на всех архитектурах есть UC.

Или я неправ? :)

Ой тут даже не драйвер, а /dev/mem. Все еще хуже.

> Что ж ты про барьеры не написал? :)

смешно, но я собирался. потом передумал, вопрос-то
не про это. но барьеры там тоже нужны, верно.

насколько я знаю, чтение pci memory является барьером.

> На i386 по идее драйвер может поставить области UC атрибут

а что это? uncached? он автоматом включается для памяти
выше high_memory (или если файл был открыт O_SYNC).

но это не снимает проблему барьеров, насколько я знаю.
pci может, вроде бы, переупорядочить stores.

>насколько я знаю, чтение pci memory является барьером.

ммм.. такой глупый вопрос: а что такое PCI память?
В том смысле, что как процессор понимает, что это PCI, а это не PCI память? Вот если в ia32/MTRR записан специальный атрибут для данной области, то понятно. :)

>а что это? uncached? он автоматом включается для памяти
>выше high_memory (или если файл был открыт O_SYNC).

Тогда такой вопрос? А вообще uncached на всех платформах есть? И как он включается на i386 - через атрибуты страниц или MTRR?

>но это не снимает проблему барьеров, насколько я знаю.
>pci может, вроде бы, переупорядочить stores.

Увы. :(

Ах, да, на IA32 ведь внешнее устройство может специальным сигналом заставить процессор не кэшировать ячейку памяти, к которой через системную шину идет обращение. Если это реально происходит, то тогда действительно можно не особенно беспокоится о процессорном reordering. Вот только как обстоят дела с не-IA32?

> > насколько я знаю, чтение pci memory является барьером. > > ммм.. такой глупый вопрос: а что такое PCI память?

это не вопрос глупый, это я по тупому написал, такого понятия и нет, я думаю.

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

> В том смысле, что как процессор понимает, что это PCI, > а это не PCI память?

по моему (почти уверен), он этого не знает совсем.

> А вообще uncached на всех платформах есть?

не, не знаю. думаю, да.

> И как он включается на i386 - через атрибуты страниц или > MTRR?

если говорить конкретно о /dev/mem (точнее, о всякого рода ...remap... функциях), то через атрибуты.

> Ах, да, на IA32 ведь внешнее устройство может специальным
> сигналом заставить процессор не кэшировать ячейку памяти

по моему, это не так. но я не знаю точно, сразу говорю.

там есть флажок про prefetchable, но это указание pci
chipset'у, я думаю. процессор про это и не знает.

Я просто к чему спросил.

Насчет PCI я читал, что там свои тараканы с переупорядочиванием.

Но мне просто интересно как все это происходит с точки зрения архитектурно-независимой части Linux именно для связки процессор<-> системная шина. :) Для ввода-вывода, как я понимаю, может быть важно как время, когда данные дойдут до устройства (например, для тех устройств, для которых ответ ожидается в циклах busy-wait), так и порядок (ну это совсем очевидно).

В моей книжке (М.Гук "Процессоры Pentium 4, Athlon и Duron") написано, что для IA32 кэширование управляется через:
1) специальные инструкции управление кэшем и побочным эффектом которых является управление кэшем (ну про это мы уже много говорили)
2) CR0 (PCD и PWT)
3) биты каталога страниц и таблицы страниц (PCD и PWT)
4) (486 и P5) внешняя схема может запрещать процессору кэшировать данные с системной шины установкой высокого уровня KEN#
5) WB/WT# тоже самое, что и 4) только WB->WT
6) MTRR
7) (Pentium 3) PAT

Вероятно, есть еще нюансы. :)

Впрочем, запись то у нас все равно всегда ordered на i386 (есть нюансы только с чтением), но вот как быть с другими архитектурами?

Как на них отображается тот же /dev/mem? :) Или, скажем, framebuffer.

P.S. Попробую сейчас сам поковыряться, хотя мне тут говорят, что надо делом заняться сначала. :)

>2) CR0 (PCD и PWT)
Коряво списал:
2) CR0 (CD и NW)

> Но мне просто интересно как все это происходит с точки зрения
> архитектурно-независимой части Linux именно для связки процессор
> <-> системная шина

$ grep pgprot_noncached include/asm-*

не все архитектуры определяют.

> Как на них отображается тот же /dev/mem?

я вообще не уверен, что на всех процессорах можно
работать корректно с устройством через этот файл.

если говорить о ядре, то у нас есть специальные
примитивы: readl/writel для работы с ioremaped
памятью. для i386 это просто load/store.

может быть, те процессоры, которые не имеют uncached
на уровне процессора решают эти проблемы в этих примитивах.

кстати, я вот чего не понимаю.

если мы в pte ставим _PAGE_PCD, зачем туда еще _PAGE_PWT?

однако include/asm-i386/pgtable.h:
#define pgprot_noncached(prot) \
        pgprot_val(prot) | _PAGE_PCD | _PAGE_PWT

idle:

Звучит весьма разумно. :) Ничего не скажешь.

>если мы в pte ставим _PAGE_PCD, зачем туда еще _PAGE_PWT?

У меня в книге такая таблица нарисована:
CD=0 NW=0 -> writeback
CD=0 NW=1 -> GPF
CD=1 NW=0 -> заполнение кэша запрещено, когерентность памяти поддерживается. Попадание чтение идет из кэша. Попадание записи модифицирует строки кэша и выходит на системную шину. Аннулирование строк разрешено, выполняется внешнее слежение.
CD=1 NW=1 ->заполнение кэша запрещено, когерентность памяти не поддерживается. Попадание чтения - из кэша, попадание записи модифицирует только кэш, внешнее слежение выполняется.

Так что CD=1 NW=0 наиболее разумный вариант, который наверное как раз и соответствует PCD|PWT.

Интересно, если реально при отображении fb или /dev/mem на IA32 в Linux получается честная некэшируемая память, то почему же XFree86 ковыряет MTRR? На всякий случай? Или потому что в других Юниксах не получается некэшируемая память - вот и ставит всем без разбору MTRR?

> Интересно, если реально при отображении fb или /dev/mem на IA32 в Linux
> получается честная некэшируемая память, то почему же XFree86 ковыряет MTRR?

на самом деле нам иногда нужно как раз кэшируемый доступ, может поэтому?

пример. я работал с картой видео захвата, все было ну очень медленно.
дело было в том, что они скопировали код из mmap_mem() и чтение региона
памяти видео данных было uncached. я поправил, и все заработало. конечно,
теперь я могу получить stale data в кадре, но иначе memcpy() просто не
успевал. к тому же, перед чтением кадра можно сделать wbinvd().

аналогично с fb. лучше писать быстро, а потом flush_write_buffers().
кстати, matrox, vesa ставят себе MTRR_TYPE_WRCOMB.

вопрос: а кто победит, если у нас конфликт атрибутов страниц и mtrr?

по поводу PCD и PWT. я правильно понял, PCD только на чтение действует?
я-то думал, что на запись тоже.

CD, как я понял, возможность добавлять новые строки кэша. А NW=!WT - не выводить запись сразу на системную шину.

По поводу конфликтов - вроде как действует самое жесткое ограничение на кэширование.

2idle (*) (08.12.2004 13:53:28)

> пример. я работал с картой видео захвата

Что за карта? И что это была за разработка?

idle:

>аналогично с fb. лучше писать быстро, а потом flush_write_buffers().

За счет чего, интересно, происходит ускорение?

За счет burst циклов?

Все равно же в обоих случаях мы ограничены пропускной способностью системной шины.

> > пример. я работал с картой видео захвата
>
> Что за карта? И что это была за разработка?

FlashBus, www.integraltech.com. мы используем их frame
grabber.

среди тех, что linux поддерживает, похоже, ни одного
более или менее профессионального.

> За счет чего, интересно, происходит ускорение?
> За счет burst циклов?

я думаю, да, хотя хрен его знает. к тому же я сам не мерил.

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

idle:

Понятно. Ну значит зависит от шаблонов доступа.
С одной стороны - скорость, с другой - cache thrashing (тоже неприятная вещь).

Видимо, истина где-то посередине. :)