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

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