Статья (http://execbit.ru/2011/04/04/flexsc/) рассказывает о новом механизме системных вызовов ядра Linux, который позволяет существенно сократить время исполнения приложений без необходимости их модификации.URL: http://execbit.ru/2011/04/04/flexsc/
Новость: http://www.opennet.ru/opennews/art.shtml?num=30193
вопрос знатокам: перспективная штука? графики по ссылке красивые, но... мало ли, вдруг где-то регресс будет.Линус уже одобрил или нет?
вот что нашёл ещё. картинки есть.
http://www.slideshare.net/liviosoares/flexsc-exceptionless-s...
Штука перспективная. Наибольший прирост будет в рантаймах с green threads.
спасибо
Я так думаю что уже да, судя по тексту новости, что это (будет) новый механизм в ядре Linux.
и Вам спасибо
> вопрос знатокам: перспективная штука?неизвестно. пока есть только заявления в стиле «ура, мы сделали велосипед с реактивным двигателем!»
> Линус уже одобрил или нет?
show me the code!
благодарю за ответ
Для благодарностей есть кнопочка с плюсом. Она позволяет снизить количество неинформативных комментариев.
> Для благодарностей есть кнопочка с плюсом. Она позволяет снизить количество неинформативных
> комментариев.спасибо.
:-D
>Только лишь за счет внедрения технологии в ядро, без каких либо модификаций приложений, им удалось достичь прироста производительности Apache на 116%, MySQL - на 40% и BIND - на 105%Ждемс, пока будут доступны сырцы, ибо пока сомнительно что-то. Ну и комментарии Линуса были бы кстати
Хм.. Кто знает, как устроен Windows? Какой механизм системных вызовов там?
>Хм.. Кто знает, как устроен Windows? Какой механизм системных вызовов там?это сложный вопрос. в теории они параллельны. те любой тред может инициировать системный вызов независимо от другого. но:
1. есть глобальные блокировки в самом ядре. например, работа с каталогом объектов, кучами и тд.
2. при обращении к разделяемым ресурсам порядок обработки запросов решает не ядро, а драйвер устр-ва.
Марка Руссиновича почитай. Чем больше узнаешь *nix тем более понимаешь насколько качественнее архитектура у Windows/VMS.
> Марка Руссиновича почитай. Чем больше узнаешь *nix тем более понимаешь насколько качественнее
> архитектура у Windows/VMS.то-то они за столько лет даже fork() не смогли сделать, а создание процесса тормозит неимоверно.
> то-то они за столько лет даже fork() не смогли сделать, а создание
> процесса тормозит неимоверно.Зато время переключения между процессами на 15% меньше, в 7-ке между волокнами вообще в 3-4 раза - а это решающий фактор производительности. Паттерн пул потоков криворуким в помощь. За столько лет nix никак IRP адекватным обзавестись не может.
Fork() - хромой динозавр из прошлого.
> Зато время переключения между процессами на 15% меньшеORLY? proof or GTFO.
> между волокнами
бугога. при чём тут green threads? это реализуется вообще без переключения контекстов.
> За столько лет nix никак IRP адекватным обзавестись не может.
«адекватное» — это тот ужас, который в виндовых драйверах? благодарю, не надо.
> Fork() — хромой динозавр из прошлого.
несколько кривовато сделаная, но очень удобная вещь. хотя вантузники никогда этого не поймут, потому что у них форка нет, а порождение процесса — вещь безумно дорогая.
так и быть, намекну: что будет, если поток загадит чужую память? а если рухнет всего один процесс из нескольких запущеных, и главный папа, заметив это, просто форканётся ещё раз?
>> Зато время переключения между процессами на 15% меньше
> ORLY? proof or GTFO.В гугл. На intel в доки по их фрэймам.
>> между волокнами
> бугога. при чём тут green threads? это реализуется вообще без переключения контекстов.Во во
>> За столько лет nix никак IRP адекватным обзавестись не может.
> «адекватное» — это тот ужас, который в виндовых драйверах? благодарю,
> не надо.Ну кушай глобал локи.
>> Fork() — хромой динозавр из прошлого.
> несколько кривовато сделаная, но очень удобная вещь. хотя вантузники никогда этого не
> поймут, потому что у них форка нет, а порождение процесса —
> вещь безумно дорогая.Да да будем маятся с прямой передачей данных и нормальными асинхронными функциями.
> так и быть, намекну: что будет, если поток загадит чужую память? а
> если рухнет всего один процесс из нескольких запущеных, и главный папа,
> заметив это, просто форканётся ещё раз?Будет исключение. А в вашем случае - утечка дескрипторов и памяти. Вообще загадить чужую память надо постараться. Крит секции надежно изолируют там где нужно.
Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича есть сравнение архитектур Windows и Unix.
> Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича
> есть сравнение архитектур Windows и Unix.У Руссиновича и нет. Кто утверждает обратное? Оттуда берется только архитектура винды. По сравнению подходов лучше наверно Таненбаум.
>> Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича
>> есть сравнение архитектур Windows и Unix.
> У Руссиновича и нет. Кто утверждает обратное? Оттуда берется только архитектура винды.
> По сравнению подходов лучше наверно Таненбаум.Т.е. если я понял правильно это было ваше личное мнение, а не Руссиновича ? Интересно было бы услышать аргументы с примерами.
> Интересно было бы услышать аргументы с примерами.это торололо, при попытке вытащить из него доказательства закукливается и периодически несёт бред.
просто каждый вызов сделали ассинхроным + забор батчами
до этого человечество шло 2000 лет ? )
> просто каждый вызов сделали ассинхроным + забор батчами
> до этого человечество шло 2000 лет ? )2000 лет назад были операционные системы ? )
>> просто каждый вызов сделали ассинхроным + забор батчами
>> до этого человечество шло 2000 лет ? )
> 2000 лет назад были операционные системы ? )даже андроиды были. одного на кресте выставляли демо-версией. но он потом поломался.
> даже андроиды были. одного на кресте выставляли демо-версией. но он потом поломался.:)
"Он слишком много запрещал..."
Технология впечатляет. Фороникс нервно курит в сторонке.
О, в Linux наконец-то изобрели образец проектирования Future.
ты футурами тут не бросайся.
говори конкретно и с пруфами.
> ты футурами тут не бросайся.
> говори конкретно и с пруфами.Марк Гранд "Шаблоны проектирования в Java", Новое знание, 2004, ISBN: 5-94735-047-5
Глава 9. Шаблоны проектирования для конкурирующих операций.
Future (Будущее).
с нетерпением жду ядра на жабе.
когда ожидается релиз?зыж
и прочитайте уже про юзерспейс и кернелспейс, чтобы не путать их с конкурирующими операциями.
ты не прав, этот алогритм не зависит от ЯП, ява тут ни при чём.И у меня есть сомнения в работоспособности этого механизма в случае когда каждый последующий вызов зависит от предыдущего, а это очень большой класс задач.
при чём тут ЯП, если речь идёт о системных вызовах из одного кольца в другое?
>И у меня есть сомнения в работоспособности этого механизма в случае когда каждый последующий вызов зависит от предыдущего, а это очень большой класс задач.как правило системный вызов - это обращение к тому или иному ресурсу.
а у всех уважающих себя ресурсов есть шедуллеры.
> при чём тут ЯПименно об этом я и писал
> а у всех уважающих себя ресурсов есть шедуллеры.
и? Как это относится к оверхеду от системных вызовов?
>> при чём тут ЯП
>именно об этом я и писали зачем ты это писал?
>> а у всех уважающих себя ресурсов есть шедуллеры.
>и? Как это относится к оверхеду от системных вызовов?см. сабж
> с нетерпением жду ядра на жабе.
> когда ожидается релиз?Причём тут Java? Из-за того, что в названии книги и иллюстрации кода используется этот язык?
Образцы проектирования выявили задолго до появления этого универсального языка.
А поддержка ядерной JVM уже была внедрена в Solaris в качестве экспериментального модуля.> зыж
> и прочитайте уже про юзерспейс и кернелспейс, чтобы не путать их с
> конкурирующими операциями.А я не путаю. Когда пачку операций, которые необходимо выполнить, переключая контекст выполнения "юзерспейс-ядро-юзерспейс" не по одной за раз, а собрав их все вместе, распределив последовательность и сделав одно переключение вместо нескольких, то это и есть "обязательство" по выполнению операции в БУДУЩЕМ с естественным (не нарушая семантики вызовов — пользователь ничего не знает о внутренней кухне) оповещением пользователя о результате.
>Причём тут Java?"Марк Гранд Шаблоны проектирования в Java" - ты писал?
не?
На каких шаблонах Линус изначально строил своё ядро?
Minix вестимо, читай как образец Таненбаум.
Я имел ввиду паттерны.
интересно для FreeBSD что нибудь такое появится?
> интересно для FreeBSD что нибудь такое появится?iZEN напишет на java.
тонко :)по теме: вещь вроде узкозаточеная получается пока что...
подробности на сайте автора - http://www.eecg.toronto.edu/~livio/research.shtml
есть красивая pdf-ка, а патчей нет. Код бы глянуть, что он там изобрёл, ато 116% это конечно круто, но что-то слабо верится.
> есть красивая pdf-ка, а патчей нет. Код бы глянуть, что он там
> изобрёл, ато 116% это конечно круто, но что-то слабо верится.что изобрёл — это понятно. намного интересней библиотека, которая группирует вызовы в кучки.
Их не будет.
На видео 22:35- Did it work on linux? Did you tried upstream patcher for the kernel pushes?
- No.
- Did you planned it?
- No.
- Why?!
- Because it think is a lot of timing effort that I prefer to use in another ways.
ну вот, теперь ясно: графики — обычный звездёж.
Вот злодей какой. Надо его засудить. :) Он нарушает нашу свободу, отказываясь предоставить патчи. :)
нда, видео ночером смотрел без звука, поэтому этот момент пролетел мимо, тогда все понятно. Но я думаю если идея стоящая и она не вызывает регрессий в других местах (вот тут у меня как раз сомнения), то ее изобретут снова :)
Очередной "50-ти строчный патч"? =)
Интересно, а будет ли эта технология работать и проявлять себя на легковесных дистрибутивах на старом железе?
думаю ядро не дураки делают
и уже думали о таком улучшении,
но вообще интересно мнение разработчиков ядра плюсы и минусы.
им izen-ы помогают.
> думаю ядро не дураки делаютЖираф большоооой, ему видней?
Тут и без Линуса все ясно. Разработка носит скорее академический интерес (а вот можно еще вот так вот извратиться) чем практический (а нафига?).Поясню на примере:
Предположим есть задачка, она работает 10 мс, затем делает запрос (1 мс на переключение), которое ядро отрабатывает (3 мс) и возвращает назад (еще 1 мс на переключение). Потеря процессорного времени - 2 мс, латентность - 5 мс.
Теперь оптимизируем так как говорят эти товарищи, а говорят эти товарищи буквально следующее - ну зачем терять 2 раза по 1 мс на переключение каждый раз? Дождемся десятка таких запросов и все обработает заодно, выигрыш будет 9*2 = 18 мс! Однако внимательный читатель обратил уже внимание что выросла латентность - ведь теперь рабочему процессу надо ждать не 5 мс, из которых 2 потеряны, а 2+3*10 = 32 мс. То есть теперь рабочий процесс остается заблокированным гораздо дольше - пока ядро не наберет свою пачку запросов и не обработает их все целиком. То есть на множестве несвязных запросов выигрыш по процессорному времени то будет, но будет за счет проигрыша в латентности. На одиночный задаче такой подход вообще ничего не даст, кроме увеличения общего времени запроса. Можно поиграть с этими временами, константами и тд но факт остается - общая производительность может вырасти в случае высокой частоты запросов, при этом латентность отработки запроса увеличится однозначно. Вот, например, приведен график увеличения количества запросов на апаче. А где график зависимости времени отработки запроса? Ну приложили бы, если уже все так шоколадно, для демонстрации отсутсвия побочных эффектов. Также как и график для одиночного процесса, и всем все стало бы сразу ясно. Так что отсутствие кода вполне понятно и причины их отсутствия немного лежат в плане этичности, а не недостатка времени и тд и тп. Если дать возможность каждому попробовать метод на своей задаче то сразу же станет ясно что король-то голый.
Тут собственно возникает другой вопрос - ну уж если решили сэкономить на переключении, почемы бы одно ядро не выделить под это дело целиком одно ядро? Для числа ядер от 4 и более можно получить некоторый выигрыш и без потерь в латентности. Только что-то это мне уже напоминает.
Какой вывод - смотреть первый абзац.
Another important metric for servicing Web requests
besides throughput is latency of individual requests. One
might intuitively expect that latency of requests to be
higher under FlexSC because of batching and asyn-
chronous servicing of system calls, but the opposite is the
case. Figure 13 shows the average latency of requests
when processing 256 concurrent requests (other concur-
rency levels showed similar trends). The results show that
Web requests on FlexSC are serviced within 50-60% of
the time needed on NPTL, on average.Все оказалось не так плохо как я написал выше. Даже сам автор признает что интуитивно понятно что латентность должна вырасти. Но для случая в 256 потоков есть некоторый выигрыш. Является ли это типичным случаем или нетипичным неизвестно. Возможно, в некоторых случаях скорость поступления запросов на ядро настолько высока что выигрыш получается в латентности. В насколько широком диапазоне условий это выполняется остается но совести автора, поскольку никакой возможности перепроверить свои результаты он не предоставил, что вообще выходит за рамки академической этики. Да и некоторые сравнения (например, исходный апач они берут в 200 потоков, а для своей задачи берут в 1000 потоков) тоже наводят на некоторые подозрения.
Диагонального просмотра хватило чтобы понять что в статье полно спорных моментов и мелких подтасовок. Так что поумерьте аппетит, навряд ли такое будет вообще принято. Хотя, какие-нибудь мелкие микрооптимизации может это и навеет, но речь там будет идти про проценты на определенном классе задач и ситуаций.
на хорошо грузящих камень задачах, то есть если у вас идет кодирование видео в 4 потока на 4 ядрах, автор прямо говорит "don't use this", теоретический выигрыш может быть там где часто переключается контекст
>там где часто переключается контекстУ быдлокодеров появится новая лазейка.
Читать надо внимательно, а не сочинять на ходу... Речь идет о группировке вызовов разными потоками процесса! Как раз в апаче таким потоков может быть 200 и более...
Да я как раз таки прекрасно понял что это означает. Это означает, дорогой мой, что эти 200 разных процессов останутся заблокированными пока ядро не соберет все их запросы в одно целое и не обработает за один раз. Это означает что процессы выставившие запросы в числе первых будут ждать в разы дольше чем обычно. Так понятней? Единственный случай когда выигрыш будет в латентности это случай когда сам запрос ядром обрабатывается быстрее чем переключение контекста и эти запросы идут сплошным потоком. Более того, производительность метода сильно зависит от железа - я не уверен что на целеронах или амд будет наблюдаться такая же картина. А уж что будет на других платформах и подумать страшно. В общем все сильно зависит от конкретной задачи, софта, железа, настроек и тд и для демонстрации выигрыша автор видимо подобрал наиболее оптимальные условия.Если захотите продолжить обсуждение - потрудитесь объяснить каким образом апач на 200 тредах оказался наиболее производительным вариантом при половинной загрузке проца? И нормировал ли автор увеличение производительности на увеличение загрузки проца до 65% в его методе? Это как бы говорит о том что выигрыш получается не 110% а 60%, если потрудится пересчитать на одинаковую загрузку. В общем таких спекуляций в статье достаточно чтобы усомниться в ее достоверности, а без возможности независимой перепроверки результатов тут и говорить не о чем. Своего рода желтая академическая утка.
Кстати, схожий по принципу метод уже есть в ядре - это аггрегирование запросов на запись на блочное устройство. Покрутив параметры этого оптимизатора можно получить выигрыш в каких-то конкретных условиях. Ну а в других все конечно же просядет.
Никто никого не ждет, поступающие запросы сразу же выполняются внутренним потоком FlexSC, дорогой твой.
> Разработка носит скорее академический интерес+1.
Выйгрыш будет на задачах, где системный вызов, условно говоря, ничего не значит. Например, запись в лог: write,write,close. Но я интуитивно чую, что таких мест в программах очень мало - алгоритм есть алгоритм, каждая строчка важна для последующих.
Мне кажется, "если хочешь избавиться от переключений контекста, выкинь этот контекст!". Т.е. всё исполнять в едином пространстве, а защиту осуществлять более глубоким контролем вызовов.
> Мне кажется, "если хочешь избавиться от переключений контекста,
> выкинь этот контекст!".
> Т.е. всё исполнять в едином пространстве,Очень светлая мысль. Именно так люди и делают
во всяких там Ерлангах и Го. Высокопроизводительные
сервера не надо писать на C и системных потоках,
которые нынче 1:1 практически везде.> а защиту
> осуществлять более глубоким контролем вызовов.А защита обеспечивается безопасностью языка программирования.
Другой вариант -- удешевить стоимость переключения контекста.
Вот интересная на мой взгляд статья.http://www.osp.ru/os/2007/05/4259887/
Ну и последнее -- конечно остаются средства асинхронного I/O
типа kqueue или epoll. Здесь все нужно делать руками,
и это порой нелегко.
Да и вообще - если ваша задача генерит 100500 запросов к ядру и из-за этого тормозит то править надо консерваторию, я не ядро.
Если это действительно работает и эффективно работает, то будет очень весело наблюдать как производительность приложений под wine поднимается выше, чем под виндой, на одном и том же железе.
Не переживай, Microsoft, Oracle, IBM такую халяву не пропустят.
Потом предлагаю впиндюрить
* Syscall scheduler
* Syscall Autogroup
* Syscall Branch Prediction
:)
все равно узким местом будут операции ввода/вывода на носители
прирост почувствуется только если прога на диск никуда не лезет
90% комментаторов даже не въехали в суть... при этом на ходу придумывают какие-то мифические доводы, что это плохо...
Единственный комментатор который въехал в суть. Поздравляю!
А остальные просто ее хорошо поняли ну или вникли в нее.