URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 76195
[ Назад ]

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

Отправлено opennews , 10-Апр-11 00:32 
Статья (http://execbit.ru/2011/04/04/flexsc/) рассказывает о новом механизме системных вызовов ядра Linux, который позволяет существенно сократить время исполнения приложений без необходимости их модификации.

URL: http://execbit.ru/2011/04/04/flexsc/
Новость: http://www.opennet.me/opennews/art.shtml?num=30193


Содержание

Сообщения в этом обсуждении
"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено emg81 , 10-Апр-11 00:32 
вопрос знатокам: перспективная штука? графики по ссылке красивые, но... мало ли, вдруг где-то регресс будет.

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

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено коксюзер , 10-Апр-11 01:14 
Штука перспективная. Наибольший прирост будет в рантаймах с green threads.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено emg81 , 10-Апр-11 01:28 
спасибо

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Zenittur , 10-Апр-11 02:05 
Я так думаю что уже да, судя по тексту новости, что это (будет) новый механизм в ядре Linux.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено emg81 , 10-Апр-11 02:18 
и Вам спасибо

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено anonymous , 10-Апр-11 09:15 
> вопрос знатокам: перспективная штука?

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

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

show me the code!


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено emg81 , 10-Апр-11 21:55 
благодарю за ответ

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено www2 , 11-Апр-11 07:28 
Для благодарностей есть кнопочка с плюсом. Она позволяет снизить количество неинформативных комментариев.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено emg81 , 11-Апр-11 08:36 
> Для благодарностей есть кнопочка с плюсом. Она позволяет снизить количество неинформативных
> комментариев.

спасибо.
:-D


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Аноним , 10-Апр-11 00:51 
>Только лишь за счет внедрения технологии в ядро, без каких либо модификаций приложений, им удалось достичь прироста производительности Apache на 116%, MySQL - на 40% и BIND - на 105%

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Живот , 10-Апр-11 01:29 
Хм.. Кто знает, как устроен Windows? Какой механизм системных вызовов там?

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Аноним , 10-Апр-11 08:55 
>Хм.. Кто знает, как устроен Windows? Какой механизм системных вызовов там?

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено letsmac , 12-Апр-11 12:46 
Марка Руссиновича почитай. Чем больше узнаешь *nix тем более понимаешь насколько качественнее архитектура у Windows/VMS.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено anonymous , 12-Апр-11 13:14 
> Марка Руссиновича почитай. Чем больше узнаешь *nix тем более понимаешь насколько качественнее
> архитектура у Windows/VMS.

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено letsmac , 14-Апр-11 17:25 
> то-то они за столько лет даже fork() не смогли сделать, а создание
> процесса тормозит неимоверно.

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

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено anonymous , 14-Апр-11 17:33 
> Зато время переключения между процессами на 15% меньше

ORLY? proof or GTFO.

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

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

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

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

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

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

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Аноним , 14-Апр-11 20:20 
>> Зато время переключения между процессами на 15% меньше
> ORLY? proof or GTFO.

В гугл. На intel в доки по их фрэймам.

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

Во во

>> За столько лет nix никак IRP адекватным обзавестись не может.
> «адекватное» — это тот ужас, который в виндовых драйверах? благодарю,
> не надо.

Ну кушай глобал локи.

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

Да да будем маятся с прямой передачей данных и нормальными асинхронными функциями.

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

Будет исключение. А в вашем случае - утечка дескрипторов и памяти. Вообще загадить чужую память надо постараться. Крит секции  надежно изолируют там где нужно.


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено AdVv , 14-Апр-11 15:57 
Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича есть сравнение архитектур Windows и Unix.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено letsmac , 14-Апр-11 17:27 
> Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича
> есть сравнение архитектур Windows и Unix.

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено AdVv , 14-Апр-11 20:09 
>> Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича
>> есть сравнение архитектур Windows и Unix.
> У Руссиновича и нет. Кто утверждает обратное? Оттуда берется только архитектура винды.
> По сравнению подходов лучше наверно Таненбаум.

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено anonymous , 14-Апр-11 20:29 
> Интересно было бы услышать аргументы с примерами.

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено assss , 10-Апр-11 01:34 
просто каждый вызов сделали ассинхроным + забор батчами
до этого человечество шло 2000 лет ? )

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Aquarius , 10-Апр-11 10:14 
> просто каждый вызов сделали ассинхроным + забор батчами
> до этого человечество шло 2000 лет ? )

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено anonymous , 10-Апр-11 10:25 
>> просто каждый вызов сделали ассинхроным + забор батчами
>> до этого человечество шло 2000 лет ? )
> 2000 лет назад были операционные системы ? )

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Kodir , 11-Апр-11 12:03 
> даже андроиды были. одного на кресте выставляли демо-версией. но он потом поломался.

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Анон , 10-Апр-11 01:35 
Технология впечатляет. Фороникс нервно курит в сторонке.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено iZEN , 10-Апр-11 01:39 
О, в Linux наконец-то изобрели образец проектирования Future.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено ананим , 10-Апр-11 01:41 
ты футурами тут не бросайся.
говори конкретно и с пруфами.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено iZEN , 10-Апр-11 01:50 
> ты футурами тут не бросайся.
> говори конкретно и с пруфами.

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено ананим , 10-Апр-11 02:48 
с нетерпением жду ядра на жабе.
когда ожидается релиз?

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Аноним , 10-Апр-11 03:21 
ты не прав, этот алогритм не зависит от ЯП, ява тут ни при чём.

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено ананим , 10-Апр-11 08:47 
при чём тут ЯП, если речь идёт о системных вызовах из одного кольца в другое?
>И у меня есть сомнения в работоспособности этого механизма в случае когда каждый последующий вызов зависит от предыдущего, а это очень большой класс задач.

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Аноним , 10-Апр-11 17:44 
> при чём тут ЯП

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

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

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено ssssa , 10-Апр-11 18:30 
>> при чём тут ЯП
>именно об этом я и писал

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

см. сабж


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено iZEN , 10-Апр-11 14:54 
> с нетерпением жду ядра на жабе.
> когда ожидается релиз?

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

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

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



"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено ssssa , 10-Апр-11 18:33 
>Причём тут Java?

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено umbr , 11-Апр-11 02:49 
На каких шаблонах Линус изначально строил своё ядро?

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Анон , 11-Апр-11 11:39 
Minix вестимо, читай как образец Таненбаум.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено umbr , 11-Апр-11 13:07 
Я имел ввиду паттерны.


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Аноним , 10-Апр-11 09:24 
интересно для FreeBSD что нибудь такое появится?

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено anonymous , 10-Апр-11 09:32 
> интересно для FreeBSD что нибудь такое появится?

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено анонимус , 10-Апр-11 14:33 
тонко :)

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено yaleks , 10-Апр-11 09:40 
подробности на сайте автора - http://www.eecg.toronto.edu/~livio/research.shtml

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено deadless , 10-Апр-11 10:20 
есть красивая pdf-ка, а патчей нет. Код бы глянуть, что он там изобрёл, ато 116% это конечно круто, но что-то слабо верится.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено anonymous , 10-Апр-11 10:26 
> есть красивая pdf-ка, а патчей нет. Код бы глянуть, что он там
> изобрёл, ато 116% это конечно круто, но что-то слабо верится.

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено yaleks , 10-Апр-11 10:39 
Их не будет.
На видео 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.


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено anonymous , 10-Апр-11 10:45 
ну вот, теперь ясно: графики — обычный звездёж.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Гога , 10-Апр-11 11:03 
Вот злодей какой. Надо его засудить. :) Он нарушает нашу свободу, отказываясь предоставить патчи. :)

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено deadless , 10-Апр-11 13:06 
нда, видео ночером смотрел без звука, поэтому этот момент пролетел мимо, тогда все понятно. Но я думаю если идея стоящая и она не вызывает регрессий в других местах (вот тут у меня как раз сомнения), то ее изобретут снова :)

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Аноним , 10-Апр-11 10:13 
Очередной "50-ти строчный патч"? =)

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено ua9oas интересуется Миша Рыцаревъ , 10-Апр-11 13:54 
  Интересно, а будет ли эта технология работать и проявлять себя на легковесных дистрибутивах на старом железе?

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено assss , 10-Апр-11 16:20 
думаю ядро не дураки делают
и уже думали о таком улучшении,
но вообще интересно мнение разработчиков ядра плюсы и минусы.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено ssssa , 10-Апр-11 16:55 
им izen-ы помогают.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Etch , 10-Апр-11 17:00 
> думаю ядро не дураки делают

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Аноним , 10-Апр-11 17:17 
Тут и без Линуса все ясно. Разработка носит скорее академический интерес (а вот можно еще вот так вот извратиться) чем практический (а нафига?).

Поясню на примере:

Предположим есть задачка, она работает 10 мс, затем делает запрос (1 мс на переключение), которое ядро отрабатывает (3 мс) и возвращает назад (еще 1 мс на переключение). Потеря процессорного времени - 2 мс, латентность - 5 мс.

Теперь оптимизируем так как говорят эти товарищи, а говорят эти товарищи буквально следующее - ну зачем терять 2 раза по 1 мс на переключение каждый раз? Дождемся десятка таких запросов и все обработает заодно, выигрыш будет 9*2 = 18 мс! Однако внимательный читатель обратил уже внимание что выросла латентность - ведь теперь рабочему процессу надо ждать не 5 мс, из которых 2 потеряны, а 2+3*10 = 32 мс. То есть теперь рабочий процесс остается заблокированным гораздо дольше - пока ядро не наберет свою пачку запросов и не обработает их все целиком. То есть на множестве несвязных запросов выигрыш по процессорному времени то будет, но будет за счет проигрыша в латентности. На одиночный задаче такой подход вообще ничего не даст, кроме увеличения общего времени запроса. Можно поиграть с этими временами, константами и тд но факт остается - общая производительность может вырасти в случае высокой частоты запросов, при этом латентность отработки запроса увеличится однозначно. Вот, например, приведен график увеличения количества запросов на апаче. А где график зависимости времени отработки запроса? Ну приложили бы, если уже все так шоколадно, для демонстрации отсутсвия побочных эффектов. Также как и график для одиночного процесса, и всем все стало бы сразу ясно. Так что отсутствие кода вполне понятно и причины их отсутствия немного лежат в плане этичности, а не недостатка времени  и тд и тп. Если дать возможность каждому попробовать метод на своей задаче то сразу же станет ясно что король-то голый.

Тут собственно возникает другой вопрос - ну уж если решили сэкономить на переключении, почемы бы одно ядро не выделить под это дело целиком одно ядро? Для числа ядер от 4 и более можно получить некоторый выигрыш и без потерь в латентности. Только что-то это мне уже напоминает.

Какой вывод - смотреть первый абзац.


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Аноним , 10-Апр-11 17:32 
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 потоков) тоже наводят на некоторые подозрения.


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Аноним , 10-Апр-11 17:44 
Диагонального просмотра хватило чтобы понять что в статье полно спорных моментов и мелких подтасовок. Так что поумерьте аппетит, навряд ли такое будет вообще принято. Хотя, какие-нибудь мелкие микрооптимизации может это и навеет, но речь там будет идти про проценты на определенном классе задач и ситуаций.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено deadless , 10-Апр-11 19:56 
на хорошо грузящих камень задачах, то есть если у вас идет кодирование видео в 4 потока на 4 ядрах, автор прямо говорит "don't use this", теоретический выигрыш может быть там где часто переключается контекст

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено umbr , 11-Апр-11 02:54 
>там где часто переключается контекст

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено zhnavigator , 11-Апр-11 09:41 
Читать надо внимательно, а не сочинять на ходу... Речь идет о группировке вызовов разными потоками процесса! Как раз в апаче таким потоков может быть 200 и более...

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

Если захотите продолжить обсуждение - потрудитесь объяснить каким образом апач на 200 тредах оказался наиболее производительным вариантом при половинной загрузке проца? И нормировал ли автор увеличение производительности на увеличение загрузки проца до 65% в его методе? Это как бы говорит о том что выигрыш получается не 110% а 60%, если потрудится пересчитать на одинаковую загрузку. В общем таких спекуляций в статье достаточно чтобы усомниться в ее достоверности, а без возможности независимой перепроверки результатов тут и говорить не о чем. Своего рода желтая академическая утка.

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено zhnavigator , 13-Апр-11 15:14 
Никто никого не ждет, поступающие запросы сразу же выполняются внутренним потоком FlexSC, дорогой твой.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Kodir , 11-Апр-11 12:12 
> Разработка носит скорее академический интерес

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено vle , 11-Апр-11 14:36 
> Мне кажется, "если хочешь избавиться от переключений контекста,
> выкинь этот контекст!".
> Т.е. всё исполнять в едином пространстве,

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

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

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

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

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

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


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено тру йода , 11-Апр-11 16:28 
Да и вообще - если ваша задача генерит 100500 запросов к ядру и из-за этого тормозит то править надо консерваторию, я не ядро.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Vitto74 , 10-Апр-11 21:21 
Если это действительно работает и эффективно работает, то будет очень весело наблюдать как производительность приложений под wine поднимается выше, чем под виндой, на одном и том же железе.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено pavlinux , 10-Апр-11 23:29 
Не переживай, Microsoft, Oracle, IBM такую халяву не пропустят.

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено pavlinux , 10-Апр-11 23:27 
Потом предлагаю впиндюрить
* Syscall scheduler
* Syscall Autogroup
* Syscall Branch Prediction


:)


"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Игорь , 11-Апр-11 06:24 
все равно узким местом будут операции ввода/вывода на носители
прирост почувствуется только если прога на диск никуда не лезет

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено zhnavigator , 11-Апр-11 09:45 
90% комментаторов даже не въехали в суть... при этом на ходу придумывают какие-то мифические доводы, что это плохо...

"FlexSC - новый механизм системных вызовов в ядре Linux"
Отправлено Аноним , 11-Апр-11 14:20 
Единственный комментатор который въехал в суть. Поздравляю!
А остальные просто ее хорошо поняли ну или вникли в нее.