LINUX.ORG.RU
ФорумTalks

Аппаратное копирование памяти


0

2

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

★★★★★

Ответ на: комментарий от MKuznetsov

Ты хочешь сказать, что fork производится не ядром? Хотя копируется данные userspace, копировальщик в ядре.

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Каких действий? Опиши их по шагам, какие действия нужны при копировании контроллером и какие - процессором, и почему вдруг первых меньше

Harald ★★★★★
()
Ответ на: комментарий от cvs-255

А кто будет решать как копировать? Кто будет отдавать команду на копирование тому-же контроллеру? Или подразумевается какая-то конкуренция с процессором на этом этапе?

chenger ★★
()
Ответ на: комментарий от ckotinko

это последовательно, каждая микросхема сколько при этом за один такт выдаёт?

Harald ★★★★★
()
Ответ на: комментарий от cvs-255

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

В итоге скорее всего станет наоборот медленнее.

chenger ★★
()
Ответ на: комментарий от Harald
1) преобразование адреса источника от виртуального к физическому
2) выставление адреса источника на шине адреса
3) посылка команды на чтение
4) контроллер памяти получает адрес и перенаправляет его в микросхему памяти
5) контроллер памяти передает данные на шину данных 
6) процессор считывает данные и помещает их в кеш 
7) преобразование адреса приемника от виртуального к физическому
8) выставление адреса приемника на шине адреса
9) вывод данных на шину данных
10) посылка команды на запись
11) контроллер памяти получает адрес и данные и перенаправляет их в микросхему памяти
12) увеличиваем адреса на 1
13) goto 1 

в случае же с копирователем в контроллере,

1) преобразуем адрес начала блока к физическому
2) передаем его в контроллер памяти. Если он интегрирован в процессор, то можем сделать это отдельной командой, в обход шины
3) передаем длину данных
4) контроллер памяти сам считывает данные
5) сам же и записывает
6) увеличивает счетчик на 1
5) goto 4
cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от ckotinko

Т.е. когда я хочу прочитать байт, микросхема выдает 2 кб, контроллер их считывает, все кроме нужного байты выкидывает, и передает его процу?

А когда хочу записать, то контроллер сперва считывает 2 кб, меняет нужный байт и записывает обратно?

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Профит будет на больших обьёмах данных, когда гонять данные по процессорной шине станет дольше чем сказать контроллеру нечто типа «скопируй N байт данных с адреса А по адресу Б, когда закончишь дёрни прерывание.» Данные в таком случае не уйдут дальше контроллера памяти. Но профит будет только в случае когда данные 1 - выровнены, 2 - лежат одним длинным куском без фрагментации, иначе всё будет только хуже.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от cvs-255

Т.е. когда я хочу прочитать байт, микросхема выдает 2 кб

ты где-нибудь видел микросхемы с 16384 ножками только для шины данных? :)

Harald ★★★★★
()
Ответ на: комментарий от cvs-255

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

Сие скорее для каких-нибудь GPU или DSP хорошо, или может для АМДшных фишек типа hUMA, наверное.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Но копировать то все равно придется рано или поздно. И делать это будет ядро

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от Dark_SavanT

Да, конечно. Как и с обычным DMA, в общем-то.

Хотя насчет единого куска может быть по-разному - более-менее продвинутые DMA-контроллеры умеют scatter/gather.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от Dark_SavanT

данные должны быть выровнены и не фрагментированы в физических адресах

Если данные занимают > 4 кбайт, то у нас целая страница выровненных данных

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Как и с обычным DMA, в общем-то.

которое из памяти в память не умеет. И как и проц, гоняет по шине

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

когда я смотрел описание контроллера dma, там не было память->память. Может с тех пор что и изменилось

cvs-255 ★★★★★
() автор топика

Я так понимаю, вам мало 12309 в связи с вводом-выводом, надо еще для памяти запилить? Чтоб жить совсем интересно стало?

shimon ★★★★★
()
Ответ на: комментарий от cvs-255

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

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Harald

The Active command activates an idle bank. It presents a 2-bit bank address (BA0 BA1) and a 13-bit row address (A0 A12), and causes a read of that row into the bank's array of all 16,384 column sense amplifiers. This is also known as «opening» the row. This operation has the side effect of refreshing the dynamic (capacitive) memory storage cells of that row.

ckotinko ☆☆☆
()
Ответ на: комментарий от cvs-255

ты забыл пункты

6) вызов прерывания контроллером при завершении 7) сохранение контекста 8) обработка прерывания - тут нужно искать, кто запросил копирование, куда сообщить о факте его завершения

все эти пункты жрут дофига тактов процессора

поток, который запустил копирование, должен как-то асинхронно узнать о завершении копирования, для этого он должен держать какие-то дополнительные структуры данных

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

Harald ★★★★★
()
Ответ на: комментарий от tailgunner

Собственно в таком случае предложенная идея начинает иметь смысл в виде аналога S/G DMA но для работы память<->память для блочного копирования данных.

Но я пока слабо представляю как это можно адекватно использовать в системе с вытеснением памяти. Это надо блокировать страницы которые читаем, страницы которые пишем, и пока контроллер гоняет данные из банки в банку не мешать ему. А тут у нас процесс который попросил скопировать данные вытеснили и следующий процесс хочет куда-то читать/писать, а контроллер ещё занят. Тупим-тормозим?

Dark_SavanT ★★★★★
()
Ответ на: комментарий от cvs-255

смысл в том, что теоретически никто не мешает считать все 2кб из одной строки и записать в другую. но в реале такой команды у sdram нету

ckotinko ☆☆☆
()
Ответ на: комментарий от Dark_SavanT

Вопрос планирования.

тут у нас процесс который попросил скопировать данные вытеснили и следующий процесс хочет куда-то читать/писать, а контроллер ещё занят. Тупим-тормозим?

И это хуже ситуации с отсуствием DMA память-память... ровно ничем.

tailgunner ★★★★★
()
Ответ на: комментарий от ckotinko

Because each chip accesses 8 bits of data at a time

скопировать 2кб из одного места в другое за один такт в SDRAM физически невозможно, у каждого чипа шина данных 8 бит

Harald ★★★★★
()
Последнее исправление: Harald (всего исправлений: 1)
Ответ на: комментарий от ncrmnt

У тебя данные от устройства в память едут через шину. Ибо взяться им в банках неоткуда. ТС же предлагает не гонять данные через CPU при копировании из одной области RAM в другую, а ему обьясняют зачем сие ненужно.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от ckotinko

хотя не, перечитал ещё раз, повтыкал в схему, вроде всё так, но это возможно, когда источник и назначение находятся внутри одного банка памяти, что сильно ограничивает применение

Harald ★★★★★
()

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

arturpub ★★
()
Ответ на: комментарий от Dark_SavanT

следующий процесс хочет куда-то читать/писать, а контроллер ещё занят. Тупим-тормозим?

Если он хочет просто писать/читать, то можно сделать чтобы контроллер раз через раз занимался копированием или обработкой запросов.

Если он хочет тоже копировать, то пусть подождет.

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от ckotinko

Ну да, нету. Придется через контроллер прогонять данные

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от ncrmnt

На x86 и вроде бы amd64 dma не копирует память->память

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от Harald

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

n_play
()
Ответ на: комментарий от tailgunner

Специальные контроллеры тоже O(n)

Может там хитрая память которая сама реплицироваться. Я именно об этом подумал когда увидел топик.

true_admin ★★★★★
()
Ответ на: комментарий от Dark_SavanT

с ethernet пакетом zero copy не проканает.

Щас даже remote dma есть :)

true_admin ★★★★★
()
Ответ на: комментарий от darkenshvein

Естественно, блистал, и не только в этом. Аналогии вообще нужны для пояснения процессов, но не для постановки задач.

thesis ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.