The OpenNET Project / Index page

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

FlexSC - новый механизм системных вызовов в ядре Linux

09.04.2011 23:27

Статья рассказывает о новом механизме системных вызовов ядра Linux, который позволяет существенно сократить время исполнения приложений без необходимости их модификации.

  1. Главная ссылка к новости (http://execbit.ru/2011/04/04/f...)
Автор новости: j1m
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/30193-FlexSC
Ключевые слова: FlexSC, linux, kernel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (71) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, emg81 (ok), 00:32, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    вопрос знатокам: перспективная штука? графики по ссылке красивые, но... мало ли, вдруг где-то регресс будет.

    Линус уже одобрил или нет?

    вот что нашёл ещё. картинки есть.
    http://www.slideshare.net/liviosoares/flexsc-exceptionless-system-calls-prese

     
     
  • 2.3, коксюзер (?), 01:14, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Штука перспективная. Наибольший прирост будет в рантаймах с green threads.
     
     
  • 3.4, emg81 (ok), 01:28, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    спасибо
     
  • 2.11, Zenittur (?), 02:05, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Я так думаю что уже да, судя по тексту новости, что это (будет) новый механизм в ядре Linux.
     
     
  • 3.12, emg81 (ok), 02:18, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    и Вам спасибо
     
  • 2.20, anonymous (??), 09:15, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > вопрос знатокам: перспективная штука?

    неизвестно. пока есть только заявления в стиле «ура, мы сделали велосипед с реактивным двигателем!»

    > Линус уже одобрил или нет?

    show me the code!

     
     
  • 3.52, emg81 (ok), 21:55, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    благодарю за ответ
     
     
  • 4.58, www2 (??), 07:28, 11/04/2011 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Для благодарностей есть кнопочка с плюсом. Она позволяет снизить количество неинформативных комментариев.
     
     
  • 5.59, emg81 (ok), 08:36, 11/04/2011 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > Для благодарностей есть кнопочка с плюсом. Она позволяет снизить количество неинформативных
    > комментариев.

    спасибо.
    :-D

     

  • 1.2, Аноним (-), 00:51, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    >Только лишь за счет внедрения технологии в ядро, без каких либо модификаций приложений, им удалось достичь прироста производительности Apache на 116%, MySQL - на 40% и BIND - на 105%

    Ждемс, пока будут доступны сырцы, ибо пока сомнительно что-то. Ну и комментарии Линуса были бы кстати

     
  • 1.5, Живот (?), 01:29, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хм.. Кто знает, как устроен Windows? Какой механизм системных вызовов там?
     
     
  • 2.18, Аноним (-), 08:55, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Хм.. Кто знает, как устроен Windows? Какой механизм системных вызовов там?

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

     
     
  • 3.72, letsmac (ok), 12:46, 12/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Марка Руссиновича почитай. Чем больше узнаешь *nix тем более понимаешь насколько качественнее архитектура у Windows/VMS.
     
     
  • 4.73, anonymous (??), 13:14, 12/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Марка Руссиновича почитай. Чем больше узнаешь *nix тем более понимаешь насколько качественнее
    > архитектура у Windows/VMS.

    то-то они за столько лет даже fork() не смогли сделать, а создание процесса тормозит неимоверно.

     
     
  • 5.76, letsmac (ok), 17:25, 14/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > то-то они за столько лет даже fork() не смогли сделать, а создание
    > процесса тормозит неимоверно.

    Зато время переключения между процессами на 15% меньше, в 7-ке между волокнами вообще в 3-4 раза - а это решающий фактор производительности. Паттерн пул потоков криворуким в помощь. За столько лет nix никак IRP адекватным обзавестись не может.

    Fork() - хромой динозавр из прошлого.

     
     
  • 6.78, anonymous (??), 17:33, 14/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Зато время переключения между процессами на 15% меньше

    ORLY? proof or GTFO.

    > между волокнами

    бугога. при чём тут green threads? это реализуется вообще без переключения контекстов.

    > За столько лет nix никак IRP адекватным обзавестись не может.

    «адекватное» — это тот ужас, который в виндовых драйверах? благодарю, не надо.

    > Fork() — хромой динозавр из прошлого.

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

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

     
     
  • 7.80, Аноним (-), 20:20, 14/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В гугл На intel в доки по их фрэймам Во во Ну кушай глобал локи Да да будем... большой текст свёрнут, показать
     
  • 4.75, AdVv (ok), 15:57, 14/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича есть сравнение архитектур Windows и Unix.
     
     
  • 5.77, letsmac (ok), 17:27, 14/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича
    > есть сравнение архитектур Windows и Unix.

    У Руссиновича и нет. Кто утверждает обратное? Оттуда берется только архитектура винды. По сравнению подходов лучше наверно Таненбаум.

     
     
  • 6.79, AdVv (ok), 20:09, 14/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича
    >> есть сравнение архитектур Windows и Unix.
    > У Руссиновича и нет. Кто утверждает обратное? Оттуда берется только архитектура винды.
    > По сравнению подходов лучше наверно Таненбаум.

    Т.е. если я понял правильно это было ваше личное мнение, а не Руссиновича ? Интересно было бы услышать аргументы с примерами.

     
     
  • 7.82, anonymous (??), 20:29, 14/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно было бы услышать аргументы с примерами.

    это торололо, при попытке вытащить из него доказательства закукливается и периодически несёт бред.

     

  • 1.6, assss (?), 01:34, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    просто каждый вызов сделали ассинхроным + забор батчами
    до этого человечество шло 2000 лет ? )
     
     
  • 2.26, Aquarius (ok), 10:14, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > просто каждый вызов сделали ассинхроным + забор батчами
    > до этого человечество шло 2000 лет ? )

    2000 лет назад были операционные системы ? )

     
     
  • 3.28, anonymous (??), 10:25, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • –10 +/
    >> просто каждый вызов сделали ассинхроным + забор батчами
    >> до этого человечество шло 2000 лет ? )
    > 2000 лет назад были операционные системы ? )

    даже андроиды были. одного на кресте выставляли демо-версией. но он потом поломался.

     
     
  • 4.64, Kodir (?), 12:03, 11/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > даже андроиды были. одного на кресте выставляли демо-версией. но он потом поломался.

    :)
    "Он слишком много запрещал..."

     

  • 1.7, Анон (?), 01:35, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Технология впечатляет. Фороникс нервно курит в сторонке.
     
  • 1.8, iZEN (ok), 01:39, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    О, в Linux наконец-то изобрели образец проектирования Future.
     
     
  • 2.9, ананим (?), 01:41, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ты футурами тут не бросайся.
    говори конкретно и с пруфами.
     
     
  • 3.10, iZEN (ok), 01:50, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > ты футурами тут не бросайся.
    > говори конкретно и с пруфами.

    Марк Гранд "Шаблоны проектирования в Java", Новое знание, 2004, ISBN: 5-94735-047-5
    Глава 9. Шаблоны проектирования для конкурирующих операций.
    Future (Будущее).

     
     
  • 4.14, ананим (?), 02:48, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • –3 +/
    с нетерпением жду ядра на жабе.
    когда ожидается релиз?

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

     
     
  • 5.15, Аноним (-), 03:21, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ты не прав, этот алогритм не зависит от ЯП, ява тут ни при чём.

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

     
     
  • 6.17, ананим (?), 08:47, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    при чём тут ЯП, если речь идёт о системных вызовах из одного кольца в другое?
    >И у меня есть сомнения в работоспособности этого механизма в случае когда каждый последующий вызов зависит от предыдущего, а это очень большой класс задач.

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

     
     
  • 7.46, Аноним (-), 17:44, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > при чём тут ЯП

    именно об этом я и писал

    > а у всех уважающих себя ресурсов есть шедуллеры.

    и? Как это относится к оверхеду от системных вызовов?

     
     
  • 8.47, ssssa (?), 18:30, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    и зачем ты это писал см сабж... текст свёрнут, показать
     
  • 5.39, iZEN (ok), 14:54, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > с нетерпением жду ядра на жабе.
    > когда ожидается релиз?

    Причём тут Java? Из-за того, что в названии книги и иллюстрации кода используется этот язык?
    Образцы проектирования выявили задолго до появления этого универсального языка.
    А поддержка ядерной JVM уже была внедрена в Solaris в качестве экспериментального модуля.

    > зыж
    > и прочитайте уже про юзерспейс и кернелспейс, чтобы не путать их с
    > конкурирующими операциями.

    А я не путаю. Когда пачку операций, которые необходимо выполнить, переключая контекст выполнения "юзерспейс-ядро-юзерспейс" не по одной за раз, а собрав их все вместе, распределив последовательность и сделав одно переключение вместо нескольких, то это и есть "обязательство" по выполнению операции в БУДУЩЕМ с естественным (не нарушая семантики вызовов — пользователь ничего не знает о внутренней кухне) оповещением пользователя о результате.


     
     
  • 6.48, ssssa (?), 18:33, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • –4 +/
    >Причём тут Java?

    "Марк Гранд Шаблоны проектирования в Java" - ты писал?
    не?

     
  • 2.55, umbr (ok), 02:49, 11/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    На каких шаблонах Линус изначально строил своё ядро?
     
     
  • 3.63, Анон (?), 11:39, 11/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Minix вестимо, читай как образец Таненбаум.
     
     
  • 4.67, umbr (ok), 13:07, 11/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Я имел ввиду паттерны.

     

  • 1.22, Аноним (-), 09:24, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    интересно для FreeBSD что нибудь такое появится?
     
     
  • 2.23, anonymous (??), 09:32, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > интересно для FreeBSD что нибудь такое появится?

    iZEN напишет на java.

     
     
  • 3.38, анонимус (??), 14:33, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    тонко :)

    по теме: вещь вроде узкозаточеная получается пока что...

     

  • 1.24, yaleks (??), 09:40, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    подробности на сайте автора - http://www.eecg.toronto.edu/~livio/research.shtml
     
     
  • 2.27, deadless (ok), 10:20, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    есть красивая pdf-ка, а патчей нет. Код бы глянуть, что он там изобрёл, ато 116% это конечно круто, но что-то слабо верится.
     
     
  • 3.29, anonymous (??), 10:26, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > есть красивая pdf-ка, а патчей нет. Код бы глянуть, что он там
    > изобрёл, ато 116% это конечно круто, но что-то слабо верится.

    что изобрёл — это понятно. намного интересней библиотека, которая группирует вызовы в кучки.

     
  • 3.30, yaleks (??), 10:39, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Их не будет.
    На видео 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.

     
     
  • 4.31, anonymous (??), 10:45, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну вот, теперь ясно: графики — обычный звездёж.
     
  • 4.32, Гога (?), 11:03, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вот злодей какой. Надо его засудить. :) Он нарушает нашу свободу, отказываясь предоставить патчи. :)
     
  • 4.35, deadless (ok), 13:06, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    нда, видео ночером смотрел без звука, поэтому этот момент пролетел мимо, тогда все понятно. Но я думаю если идея стоящая и она не вызывает регрессий в других местах (вот тут у меня как раз сомнения), то ее изобретут снова :)
     

  • 1.25, Аноним (-), 10:13, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очередной "50-ти строчный патч"? =)
     
  • 1.37, ua9oas интересуется Миша Рыцаревъ (?), 13:54, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
      Интересно, а будет ли эта технология работать и проявлять себя на легковесных дистрибутивах на старом железе?
     
  • 1.40, assss (?), 16:20, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    думаю ядро не дураки делают
    и уже думали о таком улучшении,
    но вообще интересно мнение разработчиков ядра плюсы и минусы.
     
     
  • 2.41, ssssa (?), 16:55, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • –3 +/
    им izen-ы помогают.
     
  • 2.42, Etch (?), 17:00, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > думаю ядро не дураки делают

    Жираф большоооой, ему видней?

     

  • 1.43, Аноним (-), 17:17, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Тут и без Линуса все ясно Разработка носит скорее академический интерес а вот ... большой текст свёрнут, показать
     
     
  • 2.44, Аноним (-), 17:32, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Another important metric for servicing Web requests besides throughput is latenc... большой текст свёрнут, показать
     
     
  • 3.45, Аноним (-), 17:44, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Диагонального просмотра хватило чтобы понять что в статье полно спорных моментов и мелких подтасовок. Так что поумерьте аппетит, навряд ли такое будет вообще принято. Хотя, какие-нибудь мелкие микрооптимизации может это и навеет, но речь там будет идти про проценты на определенном классе задач и ситуаций.
     
     
  • 4.49, deadless (ok), 19:56, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    на хорошо грузящих камень задачах, то есть если у вас идет кодирование видео в 4 потока на 4 ядрах, автор прямо говорит "don't use this", теоретический выигрыш может быть там где часто переключается контекст
     
     
  • 5.56, umbr (ok), 02:54, 11/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >там где часто переключается контекст

    У быдлокодеров появится новая лазейка.

     
  • 2.60, zhnavigator (?), 09:41, 11/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Читать надо внимательно, а не сочинять на ходу... Речь идет о группировке вызовов разными потоками процесса! Как раз в апаче таким потоков может быть 200 и более...
     
     
  • 3.66, Аноним (-), 12:29, 11/04/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да я как раз таки прекрасно понял что это означает Это означает, дорогой мой, ч... большой текст свёрнут, показать
     
     
  • 4.74, zhnavigator (?), 15:14, 13/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Никто никого не ждет, поступающие запросы сразу же выполняются внутренним потоком FlexSC, дорогой твой.
     
  • 2.65, Kodir (?), 12:12, 11/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Разработка носит скорее академический интерес

    +1.
    Выйгрыш будет на задачах, где системный вызов, условно говоря, ничего не значит. Например, запись в лог: write,write,close. Но я интуитивно чую, что таких мест в программах очень мало - алгоритм есть алгоритм, каждая строчка важна для последующих.
    Мне кажется, "если хочешь избавиться от переключений контекста, выкинь этот контекст!". Т.е. всё исполнять в едином пространстве, а защиту осуществлять более глубоким контролем вызовов.

     
     
  • 3.69, vle (ok), 14:36, 11/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне кажется, "если хочешь избавиться от переключений контекста,
    > выкинь этот контекст!".
    > Т.е. всё исполнять в едином пространстве,

    Очень светлая мысль. Именно так люди и делают
    во всяких там Ерлангах и Го. Высокопроизводительные
    сервера не надо писать на C и системных потоках,
    которые нынче 1:1 практически везде.

    > а защиту
    > осуществлять более глубоким контролем вызовов.

    А защита обеспечивается безопасностью языка программирования.

    Другой вариант -- удешевить стоимость переключения контекста.
    Вот интересная на мой взгляд статья.

    http://www.osp.ru/os/2007/05/4259887/

    Ну и последнее -- конечно остаются средства асинхронного I/O
    типа kqueue или epoll. Здесь все нужно делать руками,
    и это порой нелегко.

     
     
  • 4.70, тру йода (?), 16:28, 11/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да и вообще - если ваша задача генерит 100500 запросов к ядру и из-за этого тормозит то править надо консерваторию, я не ядро.
     

  • 1.51, Vitto74 (ok), 21:21, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если это действительно работает и эффективно работает, то будет очень весело наблюдать как производительность приложений под wine поднимается выше, чем под виндой, на одном и том же железе.
     
     
  • 2.54, pavlinux (ok), 23:29, 10/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Не переживай, Microsoft, Oracle, IBM такую халяву не пропустят.
     

  • 1.53, pavlinux (ok), 23:27, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Потом предлагаю впиндюрить
    * Syscall scheduler
    * Syscall Autogroup
    * Syscall Branch Prediction


    :)

     
  • 1.57, Игорь (??), 06:24, 11/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    все равно узким местом будут операции ввода/вывода на носители
    прирост почувствуется только если прога на диск никуда не лезет
     
  • 1.61, zhnavigator (?), 09:45, 11/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    90% комментаторов даже не въехали в суть... при этом на ходу придумывают какие-то мифические доводы, что это плохо...
     
     
  • 2.68, Аноним (-), 14:20, 11/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Единственный комментатор который въехал в суть. Поздравляю!
    А остальные просто ее хорошо поняли ну или вникли в нее.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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