Асинхронный и синхронный i/o и планировщик ядра

Это упражнение в софистике или искренний ГСМ?

Странно что еще «рунет головного мозга» не стал мемом :)
Мне просто лениво копаться в исходниках ядра.

Запись на неблокирующем сокете (вызов апишной ф-ии) в половине случаев длилась 10 мс на загруженной системе, хотя на системе без загрузки всегда проходила без таких задержек. Вот откуда и возникла такая гипотеза.

Рассказал бы что, куда и как записываешь

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

На самом деле это воспроизводится на большинстве вызовов posix api, кроме таких как getpid(), gettimeofday() и некоторых других, которые вообще не приводят к системному вызову (на современных линуксовых ядрах).

Мне просто лениво копаться в исходниках ядра.

Исходники ядра не имеют никакого отношения к делу. У тебя в хедпосте логическая дыра.

приводит к вызову syscall, что всегда приводит к вызову планировщика задач ядра. Правильно?

Лично у меня есть сомнения по поводу верности этого утверждения.

неблокирующей или асинхронной? это разные вещи. 10 мс это овер дофига, это возможно только если есть огромное количество конкурирующих потоков или если планировщик по какой-то причине отдает предпочтение не тебе.

не факт что в результате сисколла твой тред будет вытеснен

Вот это интересно. Т.е. вероятность такая всё-таки имеется?

никак не влияет на сравнение блокирующего и асинхронного io

Согласен. Наверно лучше было мне задать вопрос про худший случай для асинхронного i/o, когда каждая операция длится как минимум квант времени.

getpid() ... не приводят к системному вызову

4.2 getpid это 100% сисколл, процесс не может сам прочитать свой заголовок. другой вопрос, что glibc кеширует результат.

Неблокирующей. Но воспроизводится и на других сисколлах.

Вот это интересно. Т.е. вероятность такая всё-таки имеется?

насколько я помню, в линуксе имеется. в Соляре и BSD точно имеется, но вероятность зависит от того как близко ты подошел к грунице своего кванта времени. за линукс 100% не скажу, тем более что планировщиков-то много.

У тебя в хедпосте логическая дыра.

Да есть такое. Поставлю вопрос иначе:

Всякий ли системный вызов может привести к вытеснению планировщиком ядра текущего таска?

Всякий ли системный вызов может привести к вытеснению планировщиком ядра текущего таска?

Да. Но это бесполезный вопрос. Полезный вопрос - а при каких условиях происходит вытеснение?

http://oreilly.com/catalog/linuxkernel/chapter/ch10.html#23782

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

Не вижу там ответа на твой вопрос, но я рад, что ты его нашел.

Если я правильно понимаю, то асинхронность означает «не ждать завершения IO». То, что может произойти переключение на другую задачу — вроде бы другой вопрос.

Планировщик активируется если процесс истратил квант времени, либо вызвал явно блокирующую операцию, либо появился готовый процесс с более высоким приоритетом. А сисколл тоже затратная операция, но без явного форсирования перепланировщика.

Что такое kernel preemption ?

Нашел этот пост. Блин, чувак, скока ты уже под линукс девелопишь? Лет десять уже наверно? :)

сисколл тоже затратная операция, но без явного форсирования перепланировщика.

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

Лет десять уже наверно? :)

Почти 15

Асинхронная операция записи/чтения возвращается, когда запрос ставится в очередь.
Синхронная операция записи возвращается, когда данные записаны как минимум в буфер ядра.
Синхронная операция чтения возвращается, когда данные будут прочитаны в буфер.

Планировщик CFS, например, при прочих равных может выполнить первым тот процесс, у которого меньше использованного процессорного времени на данный момент.

Т.е. вероятность такая всё-таки имеется?

В линуксе ты вообще не можешь делать никаких допущений по поводу того когда твой код получит процессорное время. Т.е., ответ «да».

4.2 getpid это 100% сисколл

Вот тут пишут что нет: http://cvs.schmorp.de/libev/ev.pod?revision=1.433&view=markup

Щас посмотрю сырцы libc....

в чём профит от асинхронных операций

В том что когда у тебя 10к клиентов тебе не надо делать 10k нитей для их обслуживания.

Из мана:

Since glibc version 2.3.4, the glibc wrapper function for getpid()
caches PIDs, so as to avoid additional system calls when a process
calls getpid() repeatedly.

когда у тебя 10к клиентов тебе не надо делать 10k нитей для их обслуживания.

А от этого профит в чем?

Так будет быстрее и меньше будет жрать ресурсов.

Как я себе это вижу:

1. Не нужно держать кучу scheduling entities, меньше нагрузка на планировщик, меньще переключений контекста (или как это для нитей называется), выше отзывчивость тачки

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

1. Не нужен отдельный стэк на каждую нить.

1. Более оптимальное использование кэшей проца.

1. Возможно, меньше проблем с синхронизацией кода.

Вот что я могу вспомнить с-ходу.

Щас посмотрю сырцы libc....

Из мана: ... the glibc wrapper function for getpid() caches PIDs

4.2 getpid это 100% сисколл, процесс не может сам прочитать свой заголовок. другой вопрос, что glibc кеширует результат.

glibc кеширует результат.

ожидал от тебя большего ;P

Не нужно держать кучу scheduling entities, меньше нагрузка на планировщик

Это всё никуда не девается. Ну, будет у тебя планировщик в сервере.

меньще переключений контекста

Ок.

Не нужен отдельный стэк на каждую нить.

Не довод. Стек можно уменьшить до 8к - будет у тебя 80М на стеки - это что, критично?

Более оптимальное использование кэшей проца.

Не вижу, за счет чего.

Возможно, меньше проблем с синхронизацией кода.

В чисто асинхронном сервере - возможно.

Это всё никуда не девается. Ну, будет у тебя планировщик в сервере.

Он может быть устроен гораздо проще. Потом, можно и без планировщика (что не есть гуд, конечно).

Стек можно уменьшить до 8к - будет у тебя 80М на стеки - это что, критично?

Более оптимальное использование кэшей проца.

Не вижу, за счет чего.

Моя гипотеза в том что с каждым потоком ассоциированы какие-то данные которые активно используются (стэк, различные таблицы на стороне ядра итп). Чем больше нитей тем больше размер активно используемой памяти, что не есть гуд для кэша. На сколько это актуально для современных серверных процов я не знаю. Наверно, есть бенчмарки на эту тему. Щас погуглю, поставлю и посмотрю что будет. Вернее, вечером посмотрю, щас киношку смотрю.

Вообще, мне сама идея создать овердохрена потоком очень не нравится. Но на современном железе это работает.

man 10k problem: http://ru.wikipedia.org/wiki/Проблема_10000_соединений

Вот еще по той же проблеме: http://www.kegel.com/c10k.html

man 10k problem: http://ru.wikipedia.org/wiki/Проблема_10000_соединений

Ты, конечно, знаешь, сколько лет этой статье?

Несмотря на количество лет, проблема до сих пор акутальна. Ну как актуальна, epoll решает, на нем работает nginx и libevent используемый в Node.js, поэтому проблема как-бэ решена, для тех кто в теме.

Вот еще интересные мысли на тему http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent...

Несмотря на количество лет, проблема до сих пор акутальна. Ну как актуальна, epoll решает, на нем работает nginx и libevent используемый в Node.js, поэтому проблема как-бэ решена

Причем решена она уже довольно много лет назад.

Вот еще интересные мысли на тему http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent...

Don’t let the kernel do all the heavy lifting. Take packet handling, memory management, and processor scheduling out of the kernel and put it into the application, where it can be done efficiently. Let Linux handle the control plane and let the the application handle the data plane.

Да, офигенно интересно.

Причем решена она уже довольно много лет назад.

Тогда мне непонятен твой вопрос о профите того, что ненужно 10к тредов на 10к соединений держать.

Да, офигенно интересно.

Ну, наверное, на определенной стадии выжимания из железа всего чего возможно дойдешь и до такого. Не удивлюсь, если в гугле народ что-нибудь эдакое делает. Oracle, опять же, умеет использовать неразмеченные разделы в своих целях, что бы устранить оверхед от драйверов FS. Полно примеров. Если результатом таких хаков оказывается то, что тебе достаточно 100 серверов, там, где раньше надо было 10к серверов, имхо они вполне уместны.

Тогда мне непонятен твой вопрос о профите того, что ненужно 10к тредов на 10к соединений держать.

А мне непонятно, зачем для всего 10k соединений нужно озабочиваться асинхронностью.

Если результатом таких хаков оказывается то, что тебе достаточно 100 серверов, там, где раньше надо было 10к серверов, имхо они вполне уместны.

Если. Часто ли используются те же сырые разделы для Oracle.

А мне непонятно, зачем для всего 10k соединений нужно озабочиваться асинхронностью.

Ах вон оно что =). Ну я по умолчанию считаю, что когда мы говорим о асинхронности, то мы говорим о нагрузке в 60к-80к и больше конкурентных соединений. Для 10к соединений ессно не имеет смысла заморачиваться.

Часто ли используются те же сырые разделы для Oracle.

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