Исходное сообщение
"FlexSC - новый механизм системных вызовов в ядре Linux" Отправлено Аноним, 11-Апр-11 12:29
Да я как раз таки прекрасно понял что это означает. Это означает, дорогой мой, что эти 200 разных процессов останутся заблокированными пока ядро не соберет все их запросы в одно целое и не обработает за один раз.  Это означает что процессы выставившие запросы в числе первых будут ждать в разы дольше чем обычно. Так понятней? Единственный случай когда выигрыш будет в латентности это случай когда сам запрос ядром обрабатывается быстрее чем переключение контекста и эти запросы идут сплошным потоком. Более того, производительность метода сильно зависит от железа - я не уверен что на целеронах или амд будет наблюдаться такая же картина. А уж что будет на других платформах и подумать страшно. В общем все сильно зависит от конкретной задачи, софта, железа, настроек и тд и для демонстрации выигрыша автор видимо подобрал наиболее оптимальные условия. Если захотите продолжить обсуждение - потрудитесь объяснить каким образом апач на 200 тредах оказался наиболее производительным вариантом при половинной загрузке проца? И нормировал ли автор увеличение производительности на увеличение загрузки проца до 65% в его методе? Это как бы говорит о том что выигрыш получается не 110% а 60%, если потрудится пересчитать на одинаковую загрузку. В общем таких спекуляций в статье достаточно чтобы усомниться в ее достоверности, а без возможности независимой перепроверки результатов тут и говорить не о чем. Своего рода желтая академическая утка. Кстати, схожий по принципу метод уже есть в ядре - это аггрегирование запросов на запись на блочное устройство. Покрутив параметры этого оптимизатора можно получить выигрыш в каких-то конкретных условиях. Ну а в других все конечно же просядет.