2016-12-02 5 views
0

Моих ожиданий приложений в epoll_wait гораздо дольше, чем я, указанных в тайме-ауте:epoll_wait блоков для дольше таймаут

22578 09:33:46.959791 epoll_wait(5, <unfinished ...> 
22578 09:33:50.010794 <... epoll_wait resumed> [], 128, 1498) = 0 
... 
22034 09:35:07.686896 epoll_wait(5, <unfinished ...> 
22034 09:35:09.482526 <... epoll_wait resumed> [{EPOLLIN, {u32=151458248, u64=151458248}}], 128, 362) = 1 
... 
22036 09:35:41.433241 epoll_wait(5, <unfinished ...> 
22036 09:35:43.176881 <... epoll_wait resumed> [], 128, 97) = 0 

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

Время от логарифмической проверки - я получил его от strace. Что делать, чтобы сделать тайм-аут в epoll более мелкозернистым? И почему epoll_wait ТАК МНОГО НЕКОТОРЫХ?

ответ

1

documentation говорит:

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

Другими словами, тайм-аут является минимальным значением.

Но такие большие задержки не случаются, когда машина не работает. Если у вас есть ограничения в режиме реального времени, убедитесь, что ваш код действительно запущен, то есть установите соответствующую политику расписания, чтобы он не был заменен и т. Д.

+0

Я пропустил много промежуточной обработки в других потоках в моем обработать. Из этой обработки в других потоках я делаю вывод, что я не в состоянии ресурсного голода. Можете ли вы дать более конкретные идеи, как исследовать дальше? Единственная идея, которую я имею, - исследовать операции планировщика. Начните с записи перфоманса и ...? – user1641854

+0

Попробуйте запустить таймер 1 мс (с 'epoll_wait' или timerfd) в отдельном потоке и проверить его дрожание. –

+0

Я смог стабильно воспроизвести проблему, и действительно, основной причиной является планировщик. – user1641854

Смежные вопросы