The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Аноним, 10-Апр-11 17:17 
Тут и без Линуса все ясно. Разработка носит скорее академический интерес (а вот можно еще вот так вот извратиться) чем практический (а нафига?).

Поясню на примере:

Предположим есть задачка, она работает 10 мс, затем делает запрос (1 мс на переключение), которое ядро отрабатывает (3 мс) и возвращает назад (еще 1 мс на переключение). Потеря процессорного времени - 2 мс, латентность - 5 мс.

Теперь оптимизируем так как говорят эти товарищи, а говорят эти товарищи буквально следующее - ну зачем терять 2 раза по 1 мс на переключение каждый раз? Дождемся десятка таких запросов и все обработает заодно, выигрыш будет 9*2 = 18 мс! Однако внимательный читатель обратил уже внимание что выросла латентность - ведь теперь рабочему процессу надо ждать не 5 мс, из которых 2 потеряны, а 2+3*10 = 32 мс. То есть теперь рабочий процесс остается заблокированным гораздо дольше - пока ядро не наберет свою пачку запросов и не обработает их все целиком. То есть на множестве несвязных запросов выигрыш по процессорному времени то будет, но будет за счет проигрыша в латентности. На одиночный задаче такой подход вообще ничего не даст, кроме увеличения общего времени запроса. Можно поиграть с этими временами, константами и тд но факт остается - общая производительность может вырасти в случае высокой частоты запросов, при этом латентность отработки запроса увеличится однозначно. Вот, например, приведен график увеличения количества запросов на апаче. А где график зависимости времени отработки запроса? Ну приложили бы, если уже все так шоколадно, для демонстрации отсутсвия побочных эффектов. Также как и график для одиночного процесса, и всем все стало бы сразу ясно. Так что отсутствие кода вполне понятно и причины их отсутствия немного лежат в плане этичности, а не недостатка времени  и тд и тп. Если дать возможность каждому попробовать метод на своей задаче то сразу же станет ясно что король-то голый.

Тут собственно возникает другой вопрос - ну уж если решили сэкономить на переключении, почемы бы одно ядро не выделить под это дело целиком одно ядро? Для числа ядер от 4 и более можно получить некоторый выигрыш и без потерь в латентности. Только что-то это мне уже напоминает.

Какой вывод - смотреть первый абзац.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру