Копирование память-память
Или если не ускорить, то как ось делает такие вещи, чтоб проц занимался другими нуждами?
Возможно что этим контроллер DMA занимается в режиме работы память-память?
И последние даже если это через DMA делается, то как под Wind'ой копировать большие области памяти?
Именно копировать, а не указатели присваивать!!!
Как ускорить данную операцию?
Или если не ускорить, то как ось делает такие вещи, чтоб проц занимался другими нуждами?
Возможно что этим контроллер DMA занимается в режиме работы память-память?
И последние даже если это через DMA делается, то как под Wind'ой копировать большие области памяти?
Именно копировать, а не указатели присваивать!!!
Проц работает с памятью быстрее, чем DMA, тем более там доступ только к первым 16mb.
Т.к. шина данных у компов 64-битная, то быстрее всего будет работать копирование через MMX регистры.
Проц работает с памятью быстрее, чем DMA, тем более там доступ только к первым 16mb.
То есть ты хочешь скахать, что у любой современной оси не более 16 метров дискового кэша и находятся они в самом начале?
Честно говоря не верю!!!
DMA на шине ISA действительно имеет такое ограничение и копирование там идёт по 2 байта, но на шине PCI такого ограничения просто не может быть (16 MB), а копирование в нём происходит по 4 байта!!!
Не лучше ли ему отдать заниматься рутинной работой, в то время, как проц будет обрабатывать нетривиальные задачи?
То есть ты хочешь скахать, что у любой современной оси не более 16 метров дискового кэша и находятся они в самом начале?
Честно говоря не верю!!!
DMA на шине ISA действительно имеет такое ограничение и копирование там идёт по 2 байта, но на шине PCI такого ограничения просто не может быть (16 MB), а копирование в нём происходит по 4 байта!!!
Не лучше ли ему отдать заниматься рутинной работой, в то время, как проц будет обрабатывать нетривиальные задачи?
Да, действительно дисковый кэш - 16mb, т.к. контроллер IDE взаимодействует с DMA, который передаёт по два байта и видит первые 16mb. А про PCI толком не знаю, но в любом случае копирование процессором быстрее, т.к. можно копировать QWORD'ами и не надо связываться с портами и прерываниями.
Да, действительно дисковый кэш - 16mb, т.к. контроллер IDE взаимодействует с DMA, который передаёт по два байта и видит первые 16mb. А про PCI толком не знаю, но в любом случае копирование процессором быстрее, т.к. можно копировать QWORD'ами и не надо связываться с портами и прерываниями.
А представь, что надо из кэша скинуть 10 метров, при этом чтоб DMA это сделал надо один раз сформировать запрос и проц свободен до прерывания от DMA, когда тот всё закончит. А если проц всё это делать будет, то на всё время копирования он не доступен:-(!!!
Небольшая потеря в скорости, но зато имеем проц в распоряжении!!!
А про 16 метровый кэш в нынешних осях я абсолютно не согласен, хотя и не знаю сколько он насамом деле!!!
Зачем использовать старый ISA, когда на новых матерях его даже нет?
Если у тя Аська есть, мож обменяемся?
И ещё вопрос:
Если у тя Аська есть, мож обменяемся?
Есть, 230152.
Что касается доступной области то для стандартной AT это действительно так, ДМА может адресовать только первые 16Mb памяти.
Народ, а чего привязываем размер дискового кеша к области доступной DMA?
Что касается доступной области то для стандартной AT это действительно так, ДМА может адресовать только первые 16Mb памяти.
А то, что кто по-твоему с винта в память данные копирует?
Ты думаешь проц? Ты очень ошибаешь, если конечно ты не работаешь в PIO режиме!!!
Эти вещи возложены на DMA, а проц более важные дела делает!!!
А привязан он к дисковому кэши самым непосредственным образом, если он это всё в память с винта кидает, то дисковый кэш не может быть больше, чем область памяти, адресуемая DMA!!!
Как я уже говорил раньше - это ограничение на ISA'шной шине, коей уже давненько не наблюдается!!! А контроллер DMA на PCI'шной шине 32-разрядный, так что никаких 16 мегабайт, а полноценные 4 гига!!!
А Как я уже говорил раньше - это ограничение на ISA'шной шине, коей уже давненько не наблюдается!!! А контроллер DMA на PCI'шной шине 32-разрядный, так что никаких 16 мегабайт, а полноценные 4 гига!!!
Винты м и все CD/DVD висят не на шине PCI, а на шине IDE, где DMA 16разрядный по данным и 24разрядный по адресу.
Винты м и все CD/DVD висят не на шине PCI, а на шине IDE, где DMA 16разрядный по данным и 24разрядный по адресу.
Я уточнюсь!!!
Винты и все CD/DVD висят именно на шине PCI!!!
И простите за вопрос: что за шина такая IDE?
Нашёл исходник, где программируется именно PCI DMA, для работы с винтом, так что вот!!!
А привязан он к дисковому кэши самым непосредственным образом, если он это всё в память с винта кидает, то дисковый кэш не может быть больше, чем область памяти, адресуемая DMA!!!
Наверное не стоит так категорично это заявлять :)
Для примера лично я могу заюзать практически всю память (за исключением места под код и необходимые для работы структуры данных) не зависимо от того как данные с дика попадают в память компа, простым копированием памяти. Возможно не самый эффективный способ, но... :)
Валерий.
Уточнился!!!
Винты и все CD/DVD висят именно на шине PCI!!!
И простите за вопрос: что за шина такая IDE?
Нашёл исходник, где программируется именно PCI DMA, для работы с винтом, так что вот!!!
1. Есть такая шина IDE, стандарт на нее описывает физические и электрические параметры, также логику взаимодействия между контроллером(хостом) и блочными устройствами.
CD/DVD/HDD/(Даже сканер видел) висят на IDE/ATA а уже контроллер(хост) соединяет его с PCI. И одна из главных задач это правильно заюзать этот контроллер.
2. По поводу исходника: кинь сюда, если возможно, было бы интересно посмотреть.
Валерий.
1. Есть такая шина IDE, стандарт на нее описывает физические и электрические параметры, также логику взаимодействия между контроллером(хостом) и блочными устройствами.
CD/DVD/HDD/(Даже сканер видел) висят на IDE/ATA а уже контроллер(хост) соединяет его с PCI. И одна из главных задач это правильно заюзать этот контроллер.
2. По поводу исходника: кинь сюда, если возможно, было бы интересно посмотреть.
Валерий.
Когда на учёбу приеду, то обязательно кину, а сейчас я дома - инет тока у знакомых, да в салонах, так что возможности пока нет:-(!!!
Да, действительно дисковый кэш - 16mb, т.к. контроллер IDE взаимодействует с DMA, который передаёт по два байта и видит первые 16mb. А про PCI толком не знаю, но в любом случае копирование процессором быстрее, т.к. можно копировать QWORD'ами и не надо связываться с портами и прерываниями.
<копирование процессором быстрее>
Враньё: 1)Процессор в конечном итоге тоже обращяется к шине памяти, а DMA на прямую.
2) Как копировать с QWORD или WORD или BYTE не важно, т.к. все равно кэш строчка запишется на много быстрее, чем она сброситься в пямять.(Проверь сам:))
Линейное копирование память память должо выполняться очень быстро: порядка 200MB/s=>кому нужно быстрее?
<копирование процессором быстрее>
Враньё: 1)Процессор в конечном итоге тоже обращяется к шине памяти, а DMA на прямую.
2) Как копировать с QWORD или WORD или BYTE не важно, т.к. все равно кэш строчка запишется на много быстрее, чем она сброситься в пямять.(Проверь сам:))
Линейное копирование память память должо выполняться очень быстро: порядка 200MB/s=>кому нужно быстрее?
Дык кто всё-таки выполняет копирование память-память? Проц, или DMA?
И как в винде выполнять копирование или заполнение больших участков памяти?
Дык кто всё-таки выполняет копирование память-память? Проц, или DMA?
И как в винде выполнять копирование или заполнение больших участков памяти?
Я к сожалению не нашел линку, там один парень сделал несколько разных версий функции memcpy. Cамая быстрая была с использованием MMX регистров и PREFETCH команды.
Что касается DMA, то я видел только код работающий на 286-ых AT-ных машинках, больше использования DMA для копирования память-память я не видел.
Я к сожалению не нашел линку, там один парень сделал несколько разных версий функции memcpy. Cамая быстрая была с использованием MMX регистров и PREFETCH команды.
Что касается DMA, то я видел только код работающий на 286-ых AT-ных машинках, больше использования DMA для копирования память-память я не видел.
Значит быстрее чем:
mov esi,...
mov edi,...
mov ecx,...
Copy:
movq mm0,[esi]
movq [edi],mm0
add esi,8
add edi,8
dec ecx
jnz Copy
emms
способа в винде нет?
Значит быстрее чем:
mov esi,...
mov edi,...
mov ecx,...
Copy:
movq mm0,[esi]
movq [edi],mm0
add esi,8
add edi,8
dec ecx
jnz Copy
emms
способа в винде нет?
В общем случае нет. Для каждого процессора по разному, для какого-то быстрее будет через xmm регистры, но всё равно 128бит по шине данных можно переместить только за два прохода.
Дык кто всё-таки выполняет копирование память-память? Проц, или DMA?
И как в винде выполнять копирование или заполнение больших участков памяти?
Вопервых, мы на какую скорость ориентируемся?
Во вторых, почему реч идет об копирование именно в винде? Что сама винда сама как-то умеет быстро копировать большие объемы?
В третьих большие участки памяти это GBты?
Вопервых, мы на какую скорость ориентируемся?
Во вторых, почему реч идет об копирование именно в винде? Что сама винда сама как-то умеет быстро копировать большие объемы?
В третьих большие участки памяти это GBты?
Что значит на какую скорость?
А в винде потомучто я ЛАМЕР и работаю и пишу в винде и под винду!!!
А почему она этого не должна уметь? Она всем железом управляет, так что это её непосредственная задача!!!
Нету на PCI никакого контроллера DMA как специального отдельного устройства. Шина сама по себе обеспечивает обмен данными своих устройств и функций устройств через хостовый мост (северный он или южный - не помню) с ОЗУ компьютера. Другое дело, что отдельное устройство, логически "расположенное" в пространстве портов отжившего своё (и уже очень давно) контроллера DMA шины ISA, занимается тем, что эмулирует этот контроллер для PCI-ISA моста.
ты и тут..как ось?
ты и тут..как ось?
Пока я тут, понимаешь в разных форумах , да ещё в институте время убиваю , совсем мало остаётся на "общее интеллектуальное развитие":) Вообще, если честно, я как-то всё больше по части реализации различных интерфейсных стандартов взаимодействия с аппаратурой специалист. Системное программирование меня интересует только с этой точки зрения. Поэтому моя ОСь- не более, чем эксперимент, целью которого является - изучение возможностей ProtectedMode и встроенной поддержки многозадачности современных микропроцессоров Intel . У меня, кстати, как раз с аппаратной поддержкой TaskSwitch'ей какие-то непреодолимые трудности возникли. Я сварганил простенький монитор процессов специально для переключения через IRQ0, а он упорно не желает работать через дескриптор шлюза задачи в IDT - CPU в прединфарктное состояние RESET'а вводит. При чём, что интересно, на ту же задачу можно без проблем переключаться при запрещённых прерываниях прямым Call на её TSS.
Пока я тут, понимаешь в разных форумах , да ещё в институте время убиваю , совсем мало остаётся на "общее интеллектуальное развитие":) Вообще, если честно, я как-то всё больше по части реализации различных интерфейсных стандартов взаимодействия с аппаратурой специалист. Системное программирование меня интересует только с этой точки зрения. Поэтому моя ОСь- не более, чем эксперимент, целью которого является - изучение возможностей ProtectedMode и встроенной поддержки многозадачности современных микропроцессоров Intel . У меня, кстати, как раз с аппаратной поддержкой TaskSwitch'ей какие-то непреодолимые трудности возникли. Я сварганил простенький монитор процессов специально для переключения через IRQ0, а он упорно не желает работать через дескриптор шлюза задачи в IDT - CPU в прединфарктное состояние RESET'а вводит. При чём, что интересно, на ту же задачу можно без проблем переключаться при запрещённых прерываниях прямым Call на её TSS.
еще раз... а про калл на тсс непонил? ты тсс в IDT затолкал штоль? тобишь шедулер как отдельная задача у тя?
еще раз... а про калл на тсс непонил? ты тсс в IDT затолкал штоль? тобишь шедулер как отдельная задача у тя?
Надоели, блин - создай ты уже новую тему и общайтесь в ней, здесь другая тема!!!
ты вот ответь:
так пишется в книгах и т.д. но на p6 не так.. короч.. мол адресация.. устанавливается M/IO’ и нашину адрес кидается, контроллер памяти ловит.. но сейчас как то подругому.. как?
2 >>>>>>DRVTINY<<<<<<<
встречаемся на топике DRVtiny
злюка! :P
ты вот ответь:
так пишется в книгах и т.д. но на p6 не так.. короч.. мол адресация.. устанавливается M/IO’ и нашину адрес кидается, контроллер памяти ловит.. но сейчас как то подругому.. как?
2 >>>>>>DRVTINY<<<<<<<
встречаемся на топике DRVtiny
Да, и кстати, что там думают наши уважаемые коллеги относительно проблемы копирования память-память из кольца защиты 3 в системное адресное пространство - на самом деле проблема "обхода" защиты памяти по привилегиям всяких там DPL c RPL'ями стоит достаточно остро.
Да, и кстати, что там думают наши уважаемые коллеги относительно проблемы копирования память-память из кольца защиты 3 в системное адресное пространство - на самом деле проблема "обхода" защиты памяти по привилегиям всяких там DPL c RPL'ями стоит достаточно остро.
А решается достаточно просто:
С помощью страничной трансляции или обычным копированием памяти функцией ядра.
А решается достаточно просто:
С помощью страничной трансляции или обычным копированием памяти функцией ядра.
Т.е уведомляем ядро о своём желании переправить сообщение какому-нибудь другому процессу (не обязательно активному, да ещё и с уведомлением по схеме Request-Respond). Ядро берёт тело сообщения из стека задачи (или ещё откуда-нибудь) и копирует в своё адресное пространство. А если в сообщении процесс изъявляет желание согласовать с другим процессом открытие программного канала передачи данных (трубы, например), то ведь той же системе придётся копировать данные уже по 2 раза (чтобы обеспечить примитивы бесконфликтного обмена между процессами. Т.е чтобы не было такого, когда один процесс читает из общей области памяти то, что ещё не дописал другой процесс). Общее снижение производительности, наверное, будет ощутимо? А по поводу страничной адресации: таблица страниц занимает 4Мб + 4Кб в памяти, так что CR3 у всех процессов один и тот же должен быть (мы ж не Рокфеллеры), а это на самом деле создаёт массу проблем при выстраивании виртуального адресного пространства процессов в последовательные цепочки принадлежащих им страниц (т.е обеспечении отсутствия фрагментации _принадлежащей_ им памяти)
Т.е уведомляем ядро о своём желании переправить сообщение какому-нибудь другому процессу (не обязательно активному, да ещё и с уведомлением по схеме Request-Respond). Ядро берёт тело сообщения из стека задачи (или ещё откуда-нибудь) и копирует в своё адресное пространство. А если в сообщении процесс изъявляет желание согласовать с другим процессом открытие программного канала передачи данных (трубы, например), то ведь той же системе придётся копировать данные уже по 2 раза (чтобы обеспечить примитивы бесконфликтного обмена между процессами. Т.е чтобы не было такого, когда один процесс читает из общей области памяти то, что ещё не дописал другой процесс). Общее снижение производительности, наверное, будет ощутимо? А по поводу страничной адресации: таблица страниц занимает 4Мб + 4Кб в памяти, так что CR3 у всех процессов один и тот же должен быть (мы ж не Рокфеллеры), а это на самом деле создаёт массу проблем при выстраивании виртуального адресного пространства процессов в последовательные цепочки принадлежащих им страниц (т.е обеспечении отсутствия фрагментации _принадлежащей_ им памяти)
Не грузи так, репа болит читать.
Не грузи так, репа болит читать.
Это, конечно, ценная информация. И это всё, что Вы хотели сказать? Слава Богу, хоть рука не отвалилась - а то ведь бывают же такие ужасные случаи...
Сейчас перечитал своё сообщение. Ну, может, и правда, тяжело читать. Извиняюсь. Что делать - это у меня стиль такой "тяжёлый". Как всё-таки предлагаете pipe'ы (трубы)организовывать?
Что то типа этого, только копировать 2 раза не придется, для синхронизации доступа к данным лучше использовать неделимые команды процессора, с помощью которых можно реализовать критические секции, семафоры и т.д.
Сейчас перечитал своё сообщение. Ну, может, и правда, тяжело читать. Извиняюсь. Что делать - это у меня стиль такой "тяжёлый". Как всё-таки предлагаете pipe'ы (трубы)организовывать?
кстати.. с ентим у мя тоже запор.. думаю на прервание а в регистрах или указатель на данные или сами они... есть идеи?
кстати.. с ентим у мя тоже запор.. думаю на прервание а в регистрах или указатель на данные или сами они... есть идеи?
Читая сообщения CodeWorld, чувствую себя непроходимым тупицей.
Казалось бы, ну чего тут непонятного: Феликс думает на прерывание (надеюсь, для прерывания это не имеет негативных последствий), а прерывание на него, очевидно не думает. В общем, судя по всему, назрела конфликтная ситуация. Запор то есть, ну или на компьютерном жаргоне-клинч (что на самом деле несколько иной,хоть и близкий, смысл имеет, т.е не связанный с физиологией живых организмов). Ведь совершенно ясно, что прерывание - это всё-таки не Tefal, перманентно только и занятая решением судеб мира. Зачем прерыванию на кого-то чем-то думать? А вот всё равно покоя не даёт это прерывание, зараза. Думаешь на него, думаешь, в регистры заботливо данные стопочками укладываешь, предусмотрительно потенциальные возможности реализации всяких там альтернативных вариантов, знакомых ещё по спец. бойскаутскому курсу "ориентирования на местности", изучаешь... А в результате - чёрная неблагодарность и полная непроходимость (органиченная пропускная способность) со стороны цилиндричеких каналов, а также ступорящая на корню все благие начинания ущербность несознательных прерываний. Так и живём...
Если же серьёзно, обмен сообщениями пользовательских процессов с ядром всё-таки осуществляется не через программные ЛОВУШКИ (это то, что Феликс прерываниями называет), а через шлюзы (обычно через RQ Gates), позволяющие низкопривилегированному пользовательскому процессу временно передавать управление коду высокопривилегированных сервисов, исполняющихся в контексте ядра (на 0-ом уровне привилегий).