Здравствуйте, koandrew, Вы писали:
S>>Я имел ввиду данные из сети или диска, которые проходят через cpu. K>Кто тебе сказал такую ерунду? K>Почитай, что такое DMA. Процессор может вообще не прикасаться к данным, а будет только рулить процессом, программируя контроллер DMA и/или девайсы, умеющие в bus mastering. Именно благодаря этому даже в самых высокоскоростных сетевых устройствах используются относительно маломощные процессоры. Или, например, на моей платке с FPGA процессор, работающий на частоте в 100 МГц, умудряется выдавать FullHD (и даже 4к) видео через DisplayPort выход.
Я знаю про DMA и знаю что копирование в память идет мимо цпу. Но то что скопировали, обработать то надо? И вот этим и занимается цпу.
Здравствуйте, Sharov, Вы писали:
S>Я знаю про DMA и знаю что копирование в память идет мимо цпу. Но то что скопировали, обработать то надо? И вот этим и занимается цпу.
Может и так, но это не обязательно. Можно полученные данные отправить другому устройству на обработку опять же через DMA. Или посмотреть на заголовок, и решить, что делать с остальными данными, даже не глядя на них. Именно так обстоит дело в случае сетевых устройств типа свитча или роутера.
Здравствуйте, Sharov, Вы писали:
S>Я допускаю простои на девстенно чистой машине, на которую только что накатил ось, но и там уже куча процессов работает.
А это у тебя масштаб времени другой, поэтому интуитивно кажется, что они там все бегут и чуть ли не спотыкаются.
Здравствуйте, andrey.desman, Вы писали:
AD>А это у тебя масштаб времени другой, поэтому интуитивно кажется, что они там все бегут и чуть ли не спотыкаются.
Вот, вот, вот, надо спускаться на уровень наносекунд и смотреть что там за жизнь. Потому что мне кажется, что процессор не продыхает, а на самом деле ему делать нечего. Для него секудна -- вечность.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Sharov, Вы писали:
S>>Я знаю про DMA и знаю что копирование в память идет мимо цпу. Но то что скопировали, обработать то надо? И вот этим и занимается цпу. K>Может и так, но это не обязательно. Можно полученные данные отправить другому устройству на обработку опять же через DMA. Или посмотреть на заголовок, и решить, что делать с остальными данными, даже не глядя на них. Именно так обстоит дело в случае сетевых устройств типа свитча или роутера.
На так там вроде вообще спец процессор для этого(asic), которые этим и занимается. До до цпу доходят только те данные, которые реально нужно обработать.
Здравствуйте, Sharov, Вы писали:
S>Какую конкретно? Я читал, перманентно перечитываю, H&P, смотрел Принстонский курс на курсере лет 6 назад про архитектуру цпу, на митовском курсе (edx) 6.004, даже делал(и) S>свою реализацию опереточного процессора с опереточной ОС. Но нигде я не встречал и не говорили, что процессор может заснуть, т.е. вообще ничего не делать. Мне казалось, что ему постоянно есть S>чем заняться... http://rsdn.org/forum/diy/7027271.1
Я ещё не встречал ISA, где не было бы команды вроде WFI (Wait For Interrupt) в том или ином виде. И уж точно таких нет среди более-менее современных, ибо это позволяет кардинально сократить энергопотребление и, как следствие, уменьшить рассеиваемую мощность и нагрев.
Ещё нужно не забывать, но не все команды процессора одинаковы в плане используемых ресурсов. Например, классический спинлок во многих ISA реализуется через атомарные инструкции, которые чаще всего сопровождаются длительным (по меркам процессора) простоем конвейера из-за большой латентности памяти, у которой тоже внутри есть свой конвейер (если мы говорим о памяти типа DDR3-4, то его длина может достигать 20 циклов), и для того, чтобы провести операцию RMW, нужно подождать как минимум до того, как этот конвейер в памяти полностью "пройдёт" и выдаст значение, которое хранится в памяти, а затем отправить в конвейвер команду на запись (дожидаться её выполнения не нужно, т.к. её исполнение гарантируется спецификацией). И всё это время конвейер процессора вынужден простаивать, дабы гарантировать атомарность. В системах с когерентным write-back кэшем ждать латентности памяти не обязательно, но есть свои сложности — время, когда эта модификация фактически появится в памяти, не детерминировано, что приводит к проблемам, если нужно синхронизироваться с устройствами за пределами домена когерентности кэша — для обеспечения синхронизации придётся принудительно "сбрасывать" кэш в память со всеми недостатками, которые это вносит. Из-за этого в современных процессорах контроллеры шин, умеющих в bus mastering, располагают в общем домене когерентности с вычислительными ядрами — это позволяет использовать преимущества write-back кэша и купировать его недостатки.
Впрочем, даже "наивная" реализация спинлока вроде load eax, [address]; jnz $-4 приведёт к простою конвейера из-за зависимости по данным (вторая команда не может выполниться, пока не станет известен результат первой). Современные суперскалярные out-of-order микроархитектуры могут загрузить конвейер ещё чем-то, дабы процессор не простаивал, но это далеко не панацея от data/control hazards, которые принципиально являются следствием появления конвейера.
Здравствуйте, Sharov, Вы писали:
S>На так там вроде вообще спец процессор для этого(asic), которые этим и занимается.
А чем этот спецпроцессор фундаментально отличается от обычного? Вроде тот же ARM и тут, и там
S>До до цпу доходят только те данные, которые реально нужно обработать.
С чего ты это взял? Особенно, учитывая, что в некоторых случаях таки нужен доступ к полному содержимому пакета.
Здравствуйте, koandrew, Вы писали:
K>Ещё нужно не забывать, но не все команды процессора одинаковы в плане используемых ресурсов. Например, классический спинлок во многих ISA реализуется через атомарные инструкции, которые чаще всего сопровождаются длительным (по меркам процессора) простоем конвейера из-за большой латентности памяти,
Здравствуйте, koandrew, Вы писали:
S>>На так там вроде вообще спец процессор для этого(asic), которые этим и занимается. K>А чем этот спецпроцессор фундаментально отличается от обычного? Вроде тот же ARM и тут, и там
Ну чем asic отличается от цпу, dsp процессоры от цпу, гпу от цпу?
Здравствуйте, Sharov, Вы писали:
S>Ну чем asic отличается от цпу, dsp процессоры от цпу, гпу от цпу?
И CPU, и GPU, и DSP являются ASIC'ами, и, более того, они могут быть все одновременно на одном ASIC'е
Здравствуйте, andrey.desman, Вы писали:
AD>Но с точки зрения ОС это все равно расход ЦПУ.
Это зависит от того, считает ли она это расходом или нет. Например, если ядро крутится в спинлоке в ожидании появления новой задачи в очереди, то весьма логично, чтобы ОС не считала это "расходом".
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, netch80, Вы писали:
N>>Нет. N>>Процессор может просто быть остановлен и ожидать прерывания. Даже если никто другой (внешнее устройство, другое ядро и т.д., его не дёрнуло) — когда таймер скажет "просыпайся и перепроверь", он пойдёт работать снова.
S>Кем он может быть остановлен?
Системным шедуллером, который распределяет приоритеты и выделяет кванты времени. Например, в винде если нет потоков в состоянии Ready (напривер потому что, все в Waiting), то шедуллер начнёт "тушить" ядра.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sharov, Вы писали:
S>Внезапно обнаружил, что не очень понимаю, как возможна загрузка cpu(всех ядер) под 100%. S>Судите сами, состоянии когда конвейер пуст и процессор вообще ничего не делает невозможно. Т.е. проц. постоянно что-то делает, переключается между процессами и тд.
Нет, когда процессору нечем заняться (нет процессов, готовых к исполнению), операционка говорит команду HLT. В результате процессор (ядро) останавливается, и ничего не делает, пока не приходит какое-нибудь аппаратное прерывание. Электричества в таком состоянии потребляется очень мало.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Sharov, Вы писали:
S>>Ну чем asic отличается от цпу, dsp процессоры от цпу, гпу от цпу? K>И CPU, и GPU, и DSP являются ASIC'ами, и, более того, они могут быть все одновременно на одном ASIC'е
Обычно таки ASICʼами принято называть схемы под спец. задачи, которые не умеют ничего другого и не умеют программироваться под общие задачи.
Хотя то, что имеет в виду Sharov — может быть чем угодно, сильно зависит от устройства. Например, у Cisco типовым вариантом являлись именно процессоры на интерфейсных платах, которые не грузили центральный процессор, а работали на основании влитых центральным процессором данных — и вот у этих интерфейсных были разные реализации, хотя большинство, AFAIR, были MIPS.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, andrey.desman, Вы писали:
AD>>Но с точки зрения ОС это все равно расход ЦПУ. K>Это зависит от того, считает ли она это расходом или нет. Например, если ядро крутится в спинлоке в ожидании появления новой задачи в очереди, то весьма логично, чтобы ОС не считала это "расходом".
Хм, по-моему, давно не осталось развитых архитектур, где для такого ожидания нужно крутиться на спинлоке.
Здравствуйте, Zhendos, Вы писали:
Z>Зачем ОС всегда переключаться между процессами?
Чтобы если есть несколько активных процессов, все они постепенно двигались куда-то, а не получалось бы так, что один процесс что-то делает, а другие стоят в ожидании.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Zhendos, Вы писали:
Z>>Зачем ОС всегда переключаться между процессами?
Pzz>Чтобы если есть несколько активных процессов, все они постепенно двигались куда-то, а не получалось бы так, что один процесс что-то делает, а другие стоят в ожидании.
А контекст куда делся при цитировании?
>Зачем ОС всегда переключаться между процессами? Если процесс на чем-то "завис" читает файл и данные с диска еще не пришли
Имелось введу что, процесс может чего-то "ждать" и тогда отдавать ему
такты CPU бессмысленно, естественно если процессы используют CPU то переключение в ОС
с разделение времени нужно.
Здравствуйте, netch80, Вы писали:
N>Обычно таки ASICʼами принято называть схемы под спец. задачи, которые не умеют ничего другого и не умеют программироваться под общие задачи.
Это очень странное определение ASIC
N>Хотя то, что имеет в виду Sharov — может быть чем угодно, сильно зависит от устройства. Например, у Cisco типовым вариантом являлись именно процессоры на интерфейсных платах, которые не грузили центральный процессор, а работали на основании влитых центральным процессором данных — и вот у этих интерфейсных были разные реализации, хотя большинство, AFAIR, были MIPS.
Все их свитчи, которые мне доводилось видеть изнутри, основаны на кучке FPGAшек — поэтому они очень гибки в плане изменения требований.
Мой поинт был в том, что вычислительные ядра в них принципиально такие же, как и в процессорах общего назначения, отличия там только в периферийных устройствах, подключенных ко внутренней процессорной шине.
Здравствуйте, netch80, Вы писали:
N>Хм, по-моему, давно не осталось развитых архитектур, где для такого ожидания нужно крутиться на спинлоке.
Это зависит от конкретной реализации, а также требований к системе. В большинстве случаев это решение (poll vs interrupt) оставляется софту — железо поддерживает оба варианта.
