White OwlНет, не применяется.
На уровне приложения - нет доступа к физической памяти.
Основная проблема для DMA это выгружаемость в своп и фрагментация страниц. На сколько я понял DMA не использует MMU и соответственно ничего не знает о TLB и виртуальной адресации.
Решается ли эта проблема залочиванием памяти через Virtuallock(Win)/mlock(nix)?
И как вариант использовать их в своем аллокаторе.
White OwlНа уровне ОС - большие объемы из одного угла RAM в другой перебрасывать не нужно.
В принципе, теоретически, это возможно. Если будешь писать свой однозадачный контроллер с прямым доступом к памяти и контроллерам - можешь сделать себе соответствующие реализации для memmove() и использовать их в С/С++.
А что понимается под однозадачным контроллером?

White OwlRAM-RAM через DMAпропущено...

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

RAM-RAM через DMAНа сколько я понял DMA не использует MMU и соответственно ничего не знает о TLB и виртуальной адресации.
Решается ли эта проблема залочиванием памяти через Virtuallock(Win)/mlock(nix)?
И как вариант использовать их в своем аллокаторе.Нет конечно. Эти локи все-го лишь попросят ОС не выгружать определенную виртуальную страницу в своп. Но замены виратуального адреса на физический оно не даст.

RAM-RAM через DMAпропущено...

А что понимается под однозадачным контроллером?Тот который занимается одной задачей естественно. Которому не нужно делать виртуальную память для своих под-программ.
Я имел ввиду именно проблему , а не задачу, т.е. препятствие которое мешает осуществить DMA - это выгрузка и фрагментация, а лок - решает её.
Тогда следующая проблема, получение физического адреса из виртуального, решается только один раз непосредственно перед запуском DMA-копирования. И далее в процессе ни MMU/TLB, ни CPU не нужны до прерывания.
Думаю многие сталкивались с обязательной необходимостью использования Virtuallock/mlock для DMA работы с RAM->Device.

А можете написать пример DMA-копирования RAM->RAM?

Basil A. SidorovRAM->RAM через DMAПрименяется ли в C/C++ для std::copy/memcpy копирование RAM->RAM через DMA?Нет, за отсутствием искомого DMA.
Пока что нашел такой вариант, но не совсем понял как пользоваться этой функцией, если кто знает приведите пример: int copy_page_range(struct mm_struct *dst_mm, struct mm_struct *src_mm, struct vm_area_struct *vma)
http://forum.ixbt.com/topic.cgi?id=26:38370-2#25] http://forum.ixbt.com/topic.cgi?id=26:38370-2#25

И такой пример, который работает на серверах с Intel® I/O Acceleration Technology вроде как быстрее, чем memcpy(SSE/movs): async-tx-api.txt
функция async_memcpy

Изопропилбез указания конкретных архитектур спор беспредметен
x86_64 (Intel/AMD)
серверные и десктопные CPU

maytonМожет лучше это заменить на какой-нить COW. Или как там
копия процесса создаётся. А так ... антипаттерн мать его.
Да.
А как насчет передачи RAM(CPU1) -> RAM(CPU2), с памяти одного процессора, в память другого для уменьшения задержек на многопроцессорной NUMA x86_64 системе?
Допустим есть сортированный массив в 1 GB, который редко обновляется, но активно параллельно используется на чтение для бинарного поиска в CPU1 и CPU2. Причем выбирается малый объем, но часто, и требует малых задержек .

White OwlRAM-RAM через DMAпропущено...

Да.
А как насчет передачи RAM(CPU1) -> RAM(CPU2), с памяти одного процессора, в память другого для уменьшения задержек на многопроцессорной NUMA x86_64 системе?
Допустим есть сортированный массив в 1 GB , который редко обновляется, но активно параллельно используется на чтение для бинарного поиска в CPU1 и CPU2. Причем выбирается малый объем, но часто, и требует малых задержек .Да и тут и нормальной жизни хватит.
CPU1 - сортирует массив и возвращает его в память, копия остается в его локальном кеше.
CPU2 - на первом запросе к массиву загружает его участок в свой кеш. Размер участка это грубо говоря размер шины. Постепенно, по мере надобности этот массив может быть целиком загружен в кеш CPU2. А если хочешь, то можно сразу после сортировки скомандовать CPU2 сделать полный скан массива, это загрузит его в локальный кеш. Последующие запросы уже будут идти к кешу.
Надобности в управлении DMA или копировании памяти нет никакой.
Маленький нюанс: массив в 1 GB ... массив может быть целиком загружен в кеш , гдеж кэш то такой взять? :)

BarloneRAM-RAM через DMAДопустим есть сортированный массив в 1 GB, который редко обновляется, но активно параллельно используется на чтение для бинарного поиска в CPU1 и CPU2. Причем выбирается малый объем, но часто, и требует малых задержек .А вы kernel driver пишите или пользовательское приложение? Если драйвер, то использование 1Gb массива весьма странно. Если пользовательское приложение - забудьте про DMA: ОС не даст вам доступа к железу.
А API OS или готовых драйверов для данной задачи не бывает?

White OwlRAM-RAM через DMAМаленький нюанс: массив в 1 GB ... массив может быть целиком загружен в кеш , гдеж кэш то такой взять? :)Подожди пару лет - будет.
И вообще, вопрос уже давно ушел от С и С++. Не пора ли закрывать или переносить в hardware?
Единственное кем это может использоваться - это C/C++ разработчики. А в ветке hardware уровень понимания этого на порядок ниже.

ИзопропилRAM-RAM через DMAА API OS или готовых драйверов для данной задачи не бывает?

а переключение в ядро,постановка запроса в очередь,уведомление о завершении,обработка прерываний ,
фиксация страниц, трансляция адресов - весь профит в 0 а то и минус не сведут?
Для RAM -> Device (видеокарточка) DMA же не сводит профит к 0. И быстрее на 20%, и процессор не загружает.

Basil A. SidorovRAM-RAM через DMAДля RAM -> Device (видеокарточка) DMA же не сводит профит к 0. И быстрее на 20%, и процессор не загружает."Когда вы говорите, Иван Васильевич ..." (ц) одна популярная комедия.
Т.е. тесты врут и в BestPractice от nVidia ошиблись и DMA-пересылка RAM -> Device (видеокарточка) медленнее чем это делает CPU?

Basil A. SidorovDMA-контроллер, о котором вы бредите, это такая железка, которая существовала во времена жесточайшей экономии активных элементов в архитектуры IBM PC - не было периферийных устройств, умеющих управлять (общей) шиной (aka busmastering), не было буферов размером более одного байта.
Вот тогда и существовала железка, имевшая четыре канала и служившая посредником между (примитивной) периферией и оперативной памятью.
А сейчас такая железка просто не нужна: массовый басмастеринг в писюковой периферии появился к середине девяностых, а приличных размеров буферы - ещё раньше.
Я лишь копирую цитаты из Intel, а вы называете это бредом. Уже писал вам про Intel IO AT, но научу вас пользоваться википедией.
http://en.wikipedia.org/wiki/I/O_Acceleration_Technology] http://en.wikipedia.org/wiki/I/O_Acceleration_Technology
авторI/O Acceleration Technology (I/OAT) is a DMA engine by Intel bundled with high-end server motherboards, that offloads memory copies from the main processor.
http://www.intel.ru/content/www/ru/ru/wireless-network/accel-technology.html] http://www.intel.ru/content/www/ru/ru/wireless-network/accel-technology.html

Модератор: спокойнее пожалуйста

Anatoly MoskovskyRAM-RAM через DMA,

Дык чего ж вы тогда спрашиваете есть ли такая возможность, когда в ссылке которую вы привели прямо написано что поддержка IOAT (включая прикрепление страниц вирт. памяти на время операции) добавлена в Линуксе начиная с 2.6.18 и в Винде с 2003sp1 (2006).

Только я вот думаю, что эта фича доступна только в режиме ядра, но не юзерскому коду.
Вот мне и интересно почему в Win2003SP1 ввели поддержку NetDMA, а в Win2012 отменили, говорит ли это о том, что есть более эффективные вещи?

Помимо этого мне интересно использовал ли кто-то фичи IOAT, не обязательно NetDMA (It's typically used for accelerating network traffic, but supports any kind of copies ) или если есть подобные у AMD и получал ли от этого профит?

Basil A. SidorovRAM-RAM через DMAТ.е. тесты врут и в BestPractice от nVidia ошиблись и DMA-пересылка RAM -> Device (видеокарточка) медленнее чем это делает CPU?
...
Я лишь копирую цитаты из Intel, а вы называете это бредом.Вы цитируете, не понимая смысла.
Во всех ваших "примерах" с памятью общаются периферийные устройства. Обмен память-железка. В этом случае - да, пересылка под управлением ЦПУ менее эффективна, нежели пересылка под управлением самой железки.
Но задача, которую вы решаете - другая. И в этой задаче нет места периферии. Просто потому, что пересылку память-память быстрее всех делает именно ЦПУ.
Такое ощущение, что вы сами с собой разговариваете.
Я в первом сообщении написал, что DMA RAM-RAM медленнее, и в чем смысл ваших выпадов убедить меня в этом же? :)
Учимся читать:
RAM->RAM через DMAПрименяется ли в C/C++ для std::copy/memcpy копирование RAM->RAM через DMA?
Может это будет быстрее или пусть даже чуть медленнее , но смысл в том, что можно заснуть на время копирования, отдав ядро другому потоку, сэкономив такты . Если конечно копируется достаточно большой объем .
Если вы не поняли, то сэкономленные такты отдаются другим потокам и как вы думаете это сказывается на производительности всего приложения в целом?

Обмен памяти с какой периферийной железкой производит интеловская функция async_memcpy.c ?

Basil A. SidorovRAM-RAM через DMAОбмен памяти с какой периферийной железкой производит интеловская функция async_memcpy.c ?Замечание про "не понимая смысла" остаётся в силе:


P.S. Укажите, кто (кроме ЦПУ) умеет (быстро или медленно) копировать память-память и мы продолжим обсуждение.
Устройство называется 5000 Series Chipset DMA Engine, а технология называется внезапно! I/OAT.

Это очевидно, что память не сама себя копирует, а делает это некий device (5000 Series Chipset DMA Engine).
Что оно из себя представляет физически, я не знаю: отдельный чип или MMU/Uncore/IMC переехавшие вместе с северным мостом на один кристалл с CPU.

Вы ответьте, что означают выделенные слова, здесь говориться, что копировать память-память может только CPU?
http://en.wikipedia.org/wiki/Direct_memory_access DMA can also be used for " memory to memory " copying or moving of data within memory. DMA can offload expensive memory operations, such as large copies or scatter-gather operations, from the CPU to a dedicated DMA engine . An implementation example is the I/O Acceleration Technology .

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.73.9125 Most of the receive packet processing time [15] is spent in copying the data from kernel buffer to user buffer . ... I/OAT offloads this copy operation with an additional DMA engine.

Вы как думаете, что это за устройство, которое ускоряет "сетевой" обмен между двумя виртуальными серверами расположенными на одном физическом сервере?
Очевидно, что тупым копированием не должно заниматься такое сложное устройство как ядро CPU.

ИзопропилRAM-RAM через DMAОчевидно, что тупым копированием не должно заниматься такое сложное устройство как ядро CPU.
а в Майкрософт почему-то решили иначе.

Значит - неочевидно
В майкрософт решили не использовать NetDMA, не очевидно что они отказались от копирования DMA память-память, может они теперь делают это используя другое/по другому названное устройство? :)

Basil A. SidorovВы ответьте, что означают выделенные слова, здесь говориться, что копировать память-память может только CPU?Разницу между "также может использоваться для" и "используется для"
"Может использоваться" - значит можно взять и использовать, и НЕ значит, что сейчас не существует якобы выдуманного мною DMA контроллера (5000 Series Chipset DMA Engine), как вы утверждали.

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

Basil A. SidorovВ IP-стеке с давних есть функции, позволяющие использовать память процесса в качестве "ядрёных буферов" и прочие оптимизации.
То, что интел реализовал какой-то из вариантов аппаратной поддержки - ну замечательно. И что?

И как по вашему реализовано, так Net-(mapped on kernel buffer RAM)->-(DMA)->user buffer(RAM) или как?

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.73.9125 Most of the receive packet processing time [15] is spent in copying the data from kernel buffer to user buffer. In particular, the ratio of useful work done by the CPU to useless overheads such as CPU stalling for memory access or data movement, decreases as we go from 1 Gbps links to 10 Gbps links [17]. Especially for data movement operations, rather than waiting for a memory copy to finish, the host CPU can process other pending packets while the copy is still in progress. I/OAT offloads this copy operation with an additional DMA engine. This is a dedicated device which can perform memory copies. As a result, while the DMA is performing the data copy, the CPU becomes free to process other pending packets. For more details regarding this feature and its implementation please refer to [15, 17, 16].

http://en.wikipedia.org/wiki/Direct_memory_access DMA can also be used for " memory to memory " copying or moving of data within memory. DMA can offload expensive memory operations, such as large copies or scatter-gather operations, from the CPU to a dedicated DMA engine . An implementation example is the I/O Acceleration Technology .
Basil A. Sidorov "также может использоваться для"
Basil A. Sidorov не может использоваться для обмена между двумя участками оперативной памяти.
Так вы определитесь то может, то не может, капризный какой. В википедии врут что I/OAT может использоваться для memory to memory?

Basil A. SidorovIP-стек предоставляет (ограниченную) возможность отобразить некоторый участок виртуального адресного пространства процесса на физическую память.
Отобразить некоторый участок виртуального адресного пространства процесса на физическую память - это делает MMU оперируя PTE и кэшируя их в TLB, и IP-стек тут абсолютно не причем.

Basil A. SidorovТак вот, в вашей цепочке:
1. (DMA) находится не в том месте;
Ну так скажите где он должен быть, вы вообще о нем не упомянули.

Вообщем вы мне скажите, я правильно понял:
1. Давно было так, Net-hardware маппился на физические адреса kernel-buffer, а копирование kernel-buffer -> user-buffer делал CPU (было медленно из-за медленной FSB)
2. С появлением I/OAT, Net-hardware маппился на физические адреса kernel-buffer, а копирование kernel-buffer -> user-buffer делал DMA engine (преодолели ограничение FSB)
3. С переносом северного моста на один кристалл с CPU, в DMA отпала необходимость, т.к. исчезла FSB, DMA лишь добавлял задержку, а копирование kernel-buffer -> user-buffer с помощью CPU позволяло заодно и кэшировать в LLC. Да и ядер стало много и загружается не весь CPU, а только одно ядро (1/4 - 1/8) CPU.

Basil A. SidorovНет, неправильно вы поняли.
Есть две основные (и взаимоисключающие) схемы работы с железками в IBM PC (в хронологическом порядке):
1. Порты ввода-вывода
2. Отображение на память
Есть прямой доступ к памяти (тот самый DMA) - это способность железки управлять обменом с памятью без участия процессора.
Последнее тысячелетие, практически любое железо умеет и прямой доступ и отображение на память.

Ок. Пару вопросов.
1. В следующей цитате, возможно имеется ли ввиду отображение железки на память и куда, на kernel buffer?
2. Имеется ли ввиду DMA-копирование с этой отображенной на память железки в память user buffer?
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.73.9125 Most of the receive packet processing time [15] is spent in copying the data from kernel buffer to user buffer . ... I/OAT offloads this copy operation with an additional DMA engine.

Basil A. SidorovRAM-RAM через DMA1. В следующей цитате, возможно имеется ли ввиду отображение железки на память и куда, на kernel buffer? Никуда . Железка обменялась данными с памятью - это физические адреса.
Программы (ядрёные или нет - неважно) работают в пространстве виртуальных адресов.
Если ядрёные и пользовательские адреса отображаются на один и тот же участок физической памяти - возникают проблемы безопасности, разграничения доступа и т.п. Если на разные - требуется копировать данные, что накладно.
Соответственно, под некоторые задачи делается API, которое "и волки сыты и овцы цели и пастуху - вечная память" :)2. Имеется ли ввиду DMA-копирование с этой отображенной на память железки в память user buffer?Нет - железка ничего не знает о виртуальных адресах.
Железка передаёт данные из "своего" адресного пространства в физическую память, всё остальное - на усмотрение операционной системы.
Ок. Значит в следующей цитате:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.73.9125 Most of the receive packet processing time [15] is spent in copying the data from kernel buffer to user buffer . ... I/OAT offloads this copy operation with an additional DMA engine.
Железка(сетевуха) никуда не отображается. И железка передаёт данные из "своего" адресного пространства в физическую память, которые не являются ни kernel-buffer, ни user-buffer, но непонятно зачем тогда они упомянуты в цитате :)

Basil A. SidorovRAM-RAM через DMA1. В следующей цитате, возможно имеется ли ввиду отображение железки на память и куда, на kernel buffer? Никуда .
Basil A. SidorovRAM-RAM через DMAЖелезка(сетевуха) никуда не отображается.Вообще-то - отображается .
Она отображается в никуда? :)

Basil A. SidorovRAM-RAM через DMAОна отображается в никуда? :)Она (железка) занимает определённый диапазон (физических) адресов. И в этом смысле она (железка) - никуда не отображается.
Basil A. SidorovВообще-то - отображается .
А как переводится mapped - отображаться?
http://lkml.indiana.edu/hypermail/linux/kernel/1105.0/00958.html mapped the mmio
The async_tx api only supports memory-to-memory transfers.