NEP 217 Опубліковано: 2011-07-21 19:34:45 Share Опубліковано: 2011-07-21 19:34:45 В 21.07.2011 в 19:30, KaYot сказав: Ну слава БГ. При получении прерывания происходит переключение контента, при чем тут конвееры и их мифические проблемы? Да притом, что при переключении контекста первым делом разрывается конвейер, очищается буфер ассоциативной трансляции... Я честно говоря не думал, что прийдется обьяснять такие прописные истины. Ссылка на сообщение Поделиться на других сайтах
KaYot 3 711 Опубліковано: 2011-07-21 19:36:10 Share Опубліковано: 2011-07-21 19:36:10 В 21.07.2011 в 19:25, NEP сказав: Цитата Если действительно большую часть процессорного времени занимает обработка прерываний - соответстывенно, код с достаточной вероятностью уже будет в кеше. Опять же, зависит от объема кеша; 6-8 МБ - вполне достаточный объем к слову, о 24+ МБ на ксеонах вообще не говорю - у меня роутерный дистрибутив занимает в минимальной развертке 13МБ оперативки, с рамдиском и т.п., следовательно, cache miss для него будут весьма редким явлением. Бред. Что значит достаточно редки? В чем измеряется "достаточная редкость"? А не поленитесь, поищите в спеках параметры для конкретного CPU процент удачных предсказаний переходов и процент попадания в кеш. Я последний раз такие данные искал еще для процессоров поколения Pentium и K6(пока на asm кодил), и цифры там были весьма впечатляющие, около 90% и то, и то. Для современных монстров с миллиардами транзисторов и кучей кеша ситуация вероятно еще лучше. В 21.07.2011 в 19:34, NEP сказав: В 21.07.2011 в 19:30, KaYot сказав: Ну слава БГ. При получении прерывания происходит переключение контента, при чем тут конвееры и их мифические проблемы? Да притом, что при переключении контекста первым делом разрывается конвейер, очищается буфер ассоциативной трансляции... Я честно говоря не думал, что прийдется обьяснять такие прописные истины. Ну разорвало его, постояли аж 14 тактов. Потом постояли еще 1к тактов пока ОС переключила контент задачи, еще 10к тактов обработали прерывание. Может стоит забыть про разрывы? Про ассоциативную трансляцию поподробнее, что-то новое. Ссылка на сообщение Поделиться на других сайтах
NEP 217 Опубліковано: 2011-07-21 19:46:06 Share Опубліковано: 2011-07-21 19:46:06 В 21.07.2011 в 19:36, KaYot сказав: А не поленитесь, поищите в спеках параметры для конкретного CPU процент удачных предсказаний переходов и процент попадания в кеш. Я последний раз такие данные искал еще для процессоров поколения Pentium и K6(пока на asm кодил), и цифры там были весьма впечатляющие, около 90% и то, и то. Для современных монстров с миллиардами транзисторов и кучей кеша ситуация вероятно еще лучше. При интенсивной обработке прерываний? 90% - это бред. В 21.07.2011 в 19:30, KaYot сказав: Ну разорвало его, постояли аж 14 тактов. Потом постояли еще 1к тактов пока ОС переключила контент задачи, еще 10к тактов обработали прерывание. Может стоит забыть про разрывы? Т.е. вы хотите сказать, что тупо одно прерывание (скажем получен сетевой пакет) приводит к потере 11к тактов? А чем "простой" отличается от разрыва конвейера? В 21.07.2011 в 19:30, KaYot сказав: Про ассоциативную трансляцию поподробнее, что-то новое. Очень старое. Обновлено в i7. TLB. Ссылка на сообщение Поделиться на других сайтах
KaYot 3 711 Опубліковано: 2011-07-21 19:50:38 Share Опубліковано: 2011-07-21 19:50:38 В 21.07.2011 в 19:46, NEP сказав: В 21.07.2011 в 19:36, KaYot сказав: А не поленитесь, поищите в спеках параметры для конкретного CPU процент удачных предсказаний переходов и процент попадания в кеш. Я последний раз такие данные искал еще для процессоров поколения Pentium и K6(пока на asm кодил), и цифры там были весьма впечатляющие, около 90% и то, и то. Для современных монстров с миллиардами транзисторов и кучей кеша ситуация вероятно еще лучше. При интенсивной обработке прерываний? 90% - это бред. Я даже не удивлен ответу, он становится классикой. Пруфлинк в студию. В 21.07.2011 в 19:46, NEP сказав: В 21.07.2011 в 19:30, KaYot сказав: Ну разорвало его, постояли аж 14 тактов. Потом постояли еще 1к тактов пока ОС переключила контент задачи, еще 10к тактов обработали прерывание. Может стоит забыть про разрывы? Т.е. вы хотите сказать, что 1-о прерывание (получен сетевой пакет) приводит к потере 11к тактов? Пакет после приема будет отправлен в iptables, почему бы и не 10к тактов? В 21.07.2011 в 19:46, NEP сказав: В 21.07.2011 в 19:30, KaYot сказав: Про ассоциативную трансляцию поподробнее, что-то новое. Очень старое. Возобновлено в i7. TLB. TLB понятно, он наверное еще с 286ого появился. Непонятно с какого лешего его очищать при каждом 'разрыве конвеера' и как(скорее даже зачем) оно в таком случае вообще работает? И что там возобновили в i7? В i5 его нет?)) Ссылка на сообщение Поделиться на других сайтах
NEP 217 Опубліковано: 2011-07-21 19:54:06 Share Опубліковано: 2011-07-21 19:54:06 В 21.07.2011 в 19:50, KaYot сказав: В 21.07.2011 в 19:46, NEP сказав: В 21.07.2011 в 19:36, KaYot сказав: А не поленитесь, поищите в спеках параметры для конкретного CPU процент удачных предсказаний переходов и процент попадания в кеш. Я последний раз такие данные искал еще для процессоров поколения Pentium и K6(пока на asm кодил), и цифры там были весьма впечатляющие, около 90% и то, и то. Для современных монстров с миллиардами транзисторов и кучей кеша ситуация вероятно еще лучше. При интенсивной обработке прерываний? 90% - это бред. Я даже не удивлен ответу, он становится классикой. Пруфлинк в студию. В 21.07.2011 в 19:46, NEP сказав: В 21.07.2011 в 19:30, KaYot сказав: Ну разорвало его, постояли аж 14 тактов. Потом постояли еще 1к тактов пока ОС переключила контент задачи, еще 10к тактов обработали прерывание. Может стоит забыть про разрывы? Т.е. вы хотите сказать, что 1-о прерывание (получен сетевой пакет) приводит к потере 11к тактов? Пакет после приема будет отправлен в iptables, почему бы и не 10к тактов? В 21.07.2011 в 19:46, NEP сказав: В 21.07.2011 в 19:30, KaYot сказав: Про ассоциативную трансляцию поподробнее, что-то новое. Очень старое. Возобновлено в i7. TLB. TLB понятно, он наверное еще с 286ого появился. Непонятно с какого лешего его очищать при каждом 'разрыве конвеера' и как(скорее даже зачем) оно в таком случае вообще работает? И что там возобновили в i7? В i5 его нет?)) Вы сначала обьясните чем "простой" отличается от разрыва конвейера. И чем обработка прерывания отличается от обработки пакета в iptables. Ссылка на сообщение Поделиться на других сайтах
KaYot 3 711 Опубліковано: 2011-07-21 19:59:03 Share Опубліковано: 2011-07-21 19:59:03 В 21.07.2011 в 19:54, NEP сказав: Вы сначала обьясните чем "простой" отличается от разрыва конвейера. Ничем. Я в течении 2 страниц пытаюсь узнать чем же так страшен простой в пару десятков тактов(по идее 14 для core) в сравнении с тысячами тактов на переключение задачи и сотнями и тысячами тактов на прием многострадального пакета от сетевого интерфейса в память. Тут даже до фаерволов и собственно роутинга дело не дошло, с многими десятками тысяч тиков.. Ссылка на сообщение Поделиться на других сайтах
NEP 217 Опубліковано: 2011-07-21 20:01:27 Share Опубліковано: 2011-07-21 20:01:27 В 21.07.2011 в 19:59, KaYot сказав: В 21.07.2011 в 19:54, NEP сказав: Вы сначала обьясните чем "простой" отличается от разрыва конвейера. Ничем. Я в течении 2 страниц пытаюсь узнать чем же так страшен простой в пару десятков тактов(по идее 14 для core) в сравнении с тысячами тактов на переключение задачи и сотнями и тысячами тактов на прием многострадального пакета от сетевого интерфейса в память. Тут даже до фаерволов и собственно роутинга дело не дошло, с многими десятками тысяч тиков.. Так страшно тем, что пока переключается контекст - конвейер считается разорваным. Ссылка на сообщение Поделиться на других сайтах
KaYot 3 711 Опубліковано: 2011-07-21 20:52:30 Share Опубліковано: 2011-07-21 20:52:30 В 21.07.2011 в 20:01, NEP сказав: В 21.07.2011 в 19:59, KaYot сказав: В 21.07.2011 в 19:54, NEP сказав: Вы сначала обьясните чем "простой" отличается от разрыва конвейера. Ничем. Я в течении 2 страниц пытаюсь узнать чем же так страшен простой в пару десятков тактов(по идее 14 для core) в сравнении с тысячами тактов на переключение задачи и сотнями и тысячами тактов на прием многострадального пакета от сетевого интерфейса в память. Тут даже до фаерволов и собственно роутинга дело не дошло, с многими десятками тысяч тиков.. Так страшно тем, что пока переключается контекст - конвейер считается разорваным. Кем считается? И чем это грозит? Сброс конвеера совершенно нормальная операция, практически никаких накладных расходов. Слово вам понравилось, что ли? Ссылка на сообщение Поделиться на других сайтах
NiTr0 584 Опубліковано: 2011-07-21 20:54:38 Share Опубліковано: 2011-07-21 20:54:38 В 21.07.2011 в 19:25, NEP сказав: Бред. Что значит достаточно редки? В чем измеряется "достаточная редкость"? То и значит. Код с достаточно высокой вероятностью уже будет в кеше. Зависит от объема кеша, объема обрабатываемого кода/данных и частоты вызова определенных участков кода. Так, если между 2 прерываниями обращение происходило скажем к 3 МБ данных, при этом код обработчика прерывания занимает 500КБ и код юзерспейс софта занимает 200 КБ, а кеш 6 МБ - вероятность того, что код при следующем вызове прерывания будет в кеше, равна 100%. Не? В 21.07.2011 в 19:25, NEP сказав: The Intel Ethernet Controller write packet data... куда? И как это вообще соотносится с упоминаемым вами переключением контекста/"разрывом конвейера"? Кстати, какой объем данных пакета считывается и анализируется при его маршрутизации в классическом случае? В 21.07.2011 в 20:01, NEP сказав: Так страшно тем, что пока переключается контекст - конвейер считается разорваным. Кем считается? Куда разорванным? Чего вы прицепились к сбросу конвейера-то вообще? Говорят же вам - основное время простоя ядра обусловлено совсем другими причинами, по сравнению с которыми сброс конвейера - блоха на слоне. Ссылка на сообщение Поделиться на других сайтах
NEP 217 Опубліковано: 2011-07-21 21:14:20 Share Опубліковано: 2011-07-21 21:14:20 В 21.07.2011 в 20:54, NiTr0 сказав: В 21.07.2011 в 19:25, NEP сказав: Бред. Что значит достаточно редки? В чем измеряется "достаточная редкость"? То и значит. Код с достаточно высокой вероятностью уже будет в кеше. Зависит от объема кеша, объема обрабатываемого кода/данных и частоты вызова определенных участков кода. Так, если между 2 прерываниями обращение происходило скажем к 3 МБ данных, при этом код обработчика прерывания занимает 500КБ и код юзерспейс софта занимает 200 КБ, а кеш 6 МБ - вероятность того, что код при следующем вызове прерывания будет в кеше, равна 100%. Не? В 21.07.2011 в 19:25, NEP сказав: The Intel Ethernet Controller write packet data... куда? И как это вообще соотносится с упоминаемым вами переключением контекста/"разрывом конвейера"? Кстати, какой объем данных пакета считывается и анализируется при его маршрутизации в классическом случае? В 21.07.2011 в 20:01, NEP сказав: Так страшно тем, что пока переключается контекст - конвейер считается разорваным. Кем считается? Куда разорванным? Чего вы прицепились к сбросу конвейера-то вообще? Говорят же вам - основное время простоя ядра обусловлено совсем другими причинами, по сравнению с которыми сброс конвейера - блоха на слоне. Вы о сбросе, я о разрыве. Хорошо. На какие операции уходит основное время и какие механизмы их обработки? Можете перечислить эти операции? Ссылка на сообщение Поделиться на других сайтах
NEP 217 Опубліковано: 2011-07-21 21:16:04 Share Опубліковано: 2011-07-21 21:16:04 В 21.07.2011 в 20:52, KaYot сказав: Кем считается? И чем это грозит? Сброс конвеера совершенно нормальная операция, практически никаких накладных расходов. Слово вам понравилось, что ли? Где я писал о "сбросе"?!!! Ссылка на сообщение Поделиться на других сайтах
Abram 98 Опубліковано: 2011-07-21 21:35:44 Share Опубліковано: 2011-07-21 21:35:44 Блин, вот зачем вы его трогали? По теме: стоит Q9550 + E1G44ET, жует около 1.5 гигов, не жужжит. Нагрузка 4-х CPU ~ 40%. Особого тюнинга нет (все вроде общеизвестное), есть даже кое-какой conntrack и NAT (но анально огорожен на нужные сети NOTRACK-ами). Важный момент: выбран легковесный дистрибутив, дабы ничего не сделалось "автоматом" и никаких "улучшений" (у меня - Arch Linux, пойдет также правильно приготовленный Gentoo либо готовый дистрибутив NiTr0 - LEAF), драйвера на карту интеловские, man igb тщательно скурен (там есть даже втупую написано: вот это и это ставьте так). Ссылка на сообщение Поделиться на других сайтах
NiTr0 584 Опубліковано: 2011-07-21 21:37:29 Share Опубліковано: 2011-07-21 21:37:29 В 21.07.2011 в 21:14, NEP сказав: На какие операции уходит основное время и какие механизмы их обработки? Можете перечислить эти операции? Писали вам уже: переключение контекста, т.е. сохранение регистров старой задачи и загрузка регистров новой задачи, и попутно - очистка конвейера, сброс TLB (кстати, сбрасывается он далеко не всегда) и прочие мелочи. Ссылка на сообщение Поделиться на других сайтах
NEP 217 Опубліковано: 2011-07-21 21:39:34 Share Опубліковано: 2011-07-21 21:39:34 В 21.07.2011 в 21:37, NiTr0 сказав: т.е. сохранение регистров старой задачи и загрузка регистров новой задачи, Что в это время делает конвейер? Он пошел погулять или участвует в проекте folding@home? Ссылка на сообщение Поделиться на других сайтах
NiTr0 584 Опубліковано: 2011-07-21 21:52:56 Share Опубліковано: 2011-07-21 21:52:56 В 21.07.2011 в 21:39, NEP сказав: Что в это время делает конвейер? Он пошел погулять или участвует в проекте folding@home? Неужто все это время он очищается? Очистился себе, и ждет пока его работой нагрузят. Довольно малое время. А далее - начинает выполнять собссно "смену контекста". К слову, почитайте о многозадачности на x86_64 и на реализации многозадачности под линем на x86, весьма интересное чтиво... Поймете, в частности, почему TLB не всегда сбрасывается (или правильнее сказать - вообще не сбрасывается, а инициализируется заранее сохраненными данными) Ссылка на сообщение Поделиться на других сайтах
NEP 217 Опубліковано: 2011-07-21 21:57:10 Share Опубліковано: 2011-07-21 21:57:10 В 21.07.2011 в 21:52, NiTr0 сказав: Очистился себе, и ждет пока его работой нагрузят. Довольно малое время. А далее - начинает выполнять собссно "смену контекста". А кто его нагрузит работой если "регистры старой задачи" еще не сохранились, а "регистры новой задачи" еще не занеслись? Ну распишите, как он собссно выполняет "смену контекста"? Ну по командам. Вы же дистрибутивы от Эльдара сами составляете. Неужели так сложно четко ответить на вопрос. Чем и как загружен конвейер в процессе как вы утверждаете сохранения "регистров старой задачи"? Я уже даже стараюсь писать вам понятными терминами. Ссылка на сообщение Поделиться на других сайтах
alk0v 21 Опубліковано: 2011-07-21 22:46:36 Share Опубліковано: 2011-07-21 22:46:36 хочешь, чтобы тема жила долго - вступи в спор с NEP-ом извините, не удержался Ссылка на сообщение Поделиться на других сайтах
NEP 217 Опубліковано: 2011-07-21 22:52:19 Share Опубліковано: 2011-07-21 22:52:19 В 21.07.2011 в 22:46, alk0v сказав: хочешь, чтобы тема жила долго - вступи в спор с NEP-ом извините, не удержался Бред. извините, не удержался Ссылка на сообщение Поделиться на других сайтах
pavlabor 1 950 Опубліковано: 2011-07-22 05:31:47 Share Опубліковано: 2011-07-22 05:31:47 Память, таблицы, очереди уже давно никто не чистит, ни на аппаратном, ни на софтовом уровне. Если инфа не обработана, стоять таймеры и подымают флаги аптайма, даже если обработана, то данные остаются в аккумуляторе, пока не перезапишутся новые. Для того чтобы очистить данные нужно тратить енергию и один цыкл ресурсов на запись, затратно это и не нужно. Проверить можете прочитав напрямую память, регистры. В связи с этим в дровах стоят анализаторы таблиц, например той же таблицы маков которую мы показываем в нашем коммутаторе PES-08, там при считывании таблицы получается такой мусор, что маком никак назвать нельзя и по флагам отделяеш корректную инфу - это аппаратное решение. По сетевой, в самой сетевой есть аккумулятор, когда пакет пришол, подымается флаг прерывания для проца, проц останавливает расчеты и обрабатывает прерывание, при этом переносит пакет себе в память. Карты ЕТ анонсировали что они сразу пишут пакет в кеш проца и подымают флаг прерывания, процу остается только решить что с ним делать. По сетевой, типа E1G44, лично у меня 99% уверености что там спецом реализованы грабли, потому как по скорости интел и так прилично поднял производительность, вот и оставили резерв на аппаратные решения и на будущее. Ссылка на сообщение Поделиться на других сайтах
andreu.mirowni4enko 1 Опубліковано: 2011-07-22 09:12:34 Share Опубліковано: 2011-07-22 09:12:34 В 21.07.2011 в 15:51, NEP сказав: - Системы на базе двух десктопных процессоров скажем i7 проигрывают двухпроцессорным системам на базе серверных процессоров Xeon 55/56xx Про какие десктопные процессоры i7 вы говорите? Ссылка на сообщение Поделиться на других сайтах
NiTr0 584 Опубліковано: 2011-07-22 09:28:07 Share Опубліковано: 2011-07-22 09:28:07 В 21.07.2011 в 21:57, NEP сказав: А кто его нагрузит работой если "регистры старой задачи" еще не сохранились, а "регистры новой задачи" еще не занеслись? Не поверите - само ядро линукса, которое собссно и занимается переключением контекста задачи. Аппаратная смена контекста в линуксе на х86 не пользуется, а в х86_64 - вообще отсутствует как таковая. В 21.07.2011 в 21:57, NEP сказав: Ну распишите, как он собссно выполняет "смену контекста"? Ну по командам. Вы же дистрибутивы от Эльдара сами составляете. Ну если вам лень погуглить - почитайте это и это. Вроде как понятным языком расписано, как именно выполняется программное переключение контекста задачи. В 21.07.2011 в 21:57, NEP сказав: Неужели так сложно четко ответить на вопрос. Чем и как загружен конвейер в процессе как вы утверждаете сохранения "регистров старой задачи"? Я уже даже стараюсь писать вам понятными терминами. Не поверите - кодом, выполняющим переключение контекста задачи Ссылка на сообщение Поделиться на других сайтах
NEP 217 Опубліковано: 2011-07-22 09:40:04 Share Опубліковано: 2011-07-22 09:40:04 В 22.07.2011 в 09:28, NiTr0 сказав: В 21.07.2011 в 21:57, NEP сказав: А кто его нагрузит работой если "регистры старой задачи" еще не сохранились, а "регистры новой задачи" еще не занеслись? Не поверите - само ядро линукса, которое собссно и занимается переключением контекста задачи. Аппаратная смена контекста в линуксе на х86 не пользуется, а в х86_64 - вообще отсутствует как таковая. В 21.07.2011 в 21:57, NEP сказав: Ну распишите, как он собссно выполняет "смену контекста"? Ну по командам. Вы же дистрибутивы от Эльдара сами составляете. Ну если вам лень погуглить - почитайте это и это. Вроде как понятным языком расписано, как именно выполняется программное переключение контекста задачи. В 21.07.2011 в 21:57, NEP сказав: Неужели так сложно четко ответить на вопрос. Чем и как загружен конвейер в процессе как вы утверждаете сохранения "регистров старой задачи"? Я уже даже стараюсь писать вам понятными терминами. Не поверите - кодом, выполняющим переключение контекста задачи Спрашиваю в третий раз. Какие операции выполняет этот код? Ну распишите по ступеням, что в этом время происходит с конвейером. Неужели так сложно. Ссылка на сообщение Поделиться на других сайтах
NEP 217 Опубліковано: 2011-07-22 09:50:07 Share Опубліковано: 2011-07-22 09:50:07 В 22.07.2011 в 09:12, andreu.mirowni4enko сказав: В 21.07.2011 в 15:51, NEP сказав: - Системы на базе двух десктопных процессоров скажем i7 проигрывают двухпроцессорным системам на базе серверных процессоров Xeon 55/56xx Про какие десктопные процессоры i7 вы говорите? 2-е системы на базе Core i7-970 против одной на базе двух Xeon 5670 в задачах маршрутизации. Ссылка на сообщение Поделиться на других сайтах
NEP 217 Опубліковано: 2011-07-22 10:01:13 Share Опубліковано: 2011-07-22 10:01:13 Ладно. В результате обработки прерывания/переключения контекста практически все блоки процессора оптимизирующие его работу, направленные на ускорение выполнения программы, улетучиваются как с белых яблонь дым (кэш, конвейер инструкций, таблица адресов переходов и TLB наполняются новыми данными, которые вытесняют существующие), а "старый" процесс оказывается заблокированным даже несмотря на то, что в системе есть ресурсы для его исполнения. В результате, на нерационаьное расходование ресурсов может уйти более 50% процентов от общего времени исполнения программы, в результате того, что каждое прерывание будет нивелировать производимые процессором оптимизации. Это и есть разрыв ВЫЧИСЛИТЕЛЬНОГО конвейера, а не тупо сброс конвейера инструкций Опять же использование регистровой памяти (т.е двух ступенчатого конвейера Register - DRAM) позволяет незначительно нивелировать латентность памяти и позволяет существенно реже разрывать вычислительный конвейер. Ссылка на сообщение Поделиться на других сайтах
KaYot 3 711 Опубліковано: 2011-07-22 10:07:22 Share Опубліковано: 2011-07-22 10:07:22 В 22.07.2011 в 09:50, NEP сказав: В 22.07.2011 в 09:12, andreu.mirowni4enko сказав: В 21.07.2011 в 15:51, NEP сказав: - Системы на базе двух десктопных процессоров скажем i7 проигрывают двухпроцессорным системам на базе серверных процессоров Xeon 55/56xx Про какие десктопные процессоры i7 вы говорите? 2-е системы на базе Core i7-970 против одной на базе двух Xeon 5670 в задачах маршрутизации. Конечно, сравнивать надо системы отличающиеся в цене в 20 раз.. Уверен, i7-980x будет быстрее чем ваши 2x5670 во всех задачах. Даже несмотря на 5-7 кратную разницу в цене только камней, а на сколько будет дороже вся система страшно представить. Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас