Компания Google предложила для включения в состав ядра Linux первый набор патчей с реализацией компонентов, необходимых для обеспечения работы модели потоков M:N. Инициатива Google связана с открытием развивавшегося за закрытыми дверями API SwitchTo для ядра Linux, обеспечивающего работу реализованной в пространстве пользователя многопоточной подсистемы, применяющей модель потоков M:N. Подсистема используется в Google для обеспечения работы сервисов, требующих минимальных задержек. Планирование и управление распределением потоков производится целиком в пространстве пользователя, что позволяет существенно снизить число операций переключения контекста за счёт минимизации выполнения системных вызовов...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53443
Ага, если кто не знает истории.В своё время в Solaris была (лучшая на тот момент) релизация нитей (aka легковесный процесс). Модель была M:N.
Ребята из ядерной группы, решая какую-то проблему Oracle'а для раскрутки проблемы быстренько написали компактную реализацию нитей в модели 1:1. И внезапно увидели ох^W весьма нехилый рост производительности. И потратили месяца четыре на выяснение --- где они лажанулись. Не нашли. Через четыре месяца эта модель пошла опцией в бету Solaris'а, и в следующем релизе стала основной (и единственной) моделью нитей в Solaris'е.
Объяснение выигрыша более простой модели получилось такое: "радикальное упрощение планировщика позволило заниматься делом, а не планированием".
В Linux'е Линус очень долго вообще отказывался делать поддержку нитей ядром. На этом месте паслись "зелёные нити" (полная х...ь как концепция, IMO). Но после большого успеха модели 1:1 у Sun, он быстро сотворил модель 1:1 в Linux'е.
Сейчас наблюдаем:
- во многие языки тянут coroutines (\equiv "зелёные нити");
- G. подтягивает супер-инновационную модель M:N.
Возможно, простая модель письма прикладнух без асинк колбэков один тред один сокет, сподвигла G. повторять достижения.
IMHO, внятное письмо на M worker N сокетов с колбэками и есть по сути M:N, только в пространстве пользователя. Но тут всем лениво, это же прикладнухи писать, пахнет своим шедулингом. Поэтому и идёт попытка один раз загнать в ядро.
Так думаю.
Ввод-вывод в нитях --- это полный абзац для планировщика в userspace.
Ему (user-space scheduler) будет очень удобно определять, какую из
u пользовательских нитей надо будить по наличию события в-в.Ядро-то изначально такую информацию имеет: "стоим на ...,
ждём события по...; случилось событие, ясно кого будить".
Надо же, какие олдфаги на опеннете всё ещё сидят. Приятно удивлён :-)Во фряхе, кстати, примерно та же история была с libkse - тоже вышло, что M:N модель слишком сложная. Но зумерам из Гугла некогда читать книги и архивы email-рассылок. Ну раз так, то грабли ждут их лбы.
А вообще, Соляра как ядро для своего времени была изрядно впереди планеты всей. Пока во фре боролись с giant lock и кидались фекалиями в Диллона, в Соляре синхронизация и нормальная работа SMP давно была сделана как надо. Ну и SMF, зоны, включая branded, с ограничениями ресурсов, ZFS, виртуализация сетевого стека, подключаемые плагинами планировщики, классы планирования - практически всё было сделано, и бОльшая часть сделана по-человечески и еще в то время, когда нынешние зумерки-разрабы типы данных в Си изучали. Но, как говорится, не родись красивой...
Сначала дождитесь рабочей реализации и делайте выводы. Сложно, да. И что? Это значит, что совсем нереализуемо? Нет. Если реализуют, будет быстро. Если нет, то нет.
Более того, если всё будет работать как надо, это покажет некомпетентность всех предыдущих разработчиков, у которых ничего не вышло и вынуждены были забросить. Не выгораживаю гугл, но выводы рано делать однозначные.
> Более того, если всё будет работать как надо, это покажет некомпетентность всех предыдущих разработчиков,Покажет разве что в альтернативно-фенезийной логике.
Остальным покажет, что запросов и юзкейсов гугля (как и бесконечных денег) у тех реализаторов не было, как впрочем и разницу в целевом железе.> у которых ничего не вышло и вынуждены были забросить.
Прекратите фантазировать.
> Не выгораживаю гугл,
Просто, как настоящий линуксоид, подлизываешь, надеясь на другие объедки с барского стола?
>подлизываешьНе проецируй свои фантазии на других. Это лишь альтернативное мнение, не более. Включат или нет не особо волнует.
>>>> "Google начал открытие реализации модели потоков M:N"
>>> покажет некомпетентность всех предыдущих разработчиков
>> подлизываешь
> Не проецируй свои фантазии на других. Это лишь альтернативное мнение, не более.Т.е. я угадал. Типичная проприетарная подстилочка.
При чём здесь проприетарщина? Как в статье, так и в обсуждении речь про СПО. У вас везде враги вашего режима в голове мерещатся. Попейте таблеточки.
> При чём здесь проприетарщина? Как в статье, так и в обсуждении речь про СПО.В обсуждении речь о восторженном подлизывании анонимом крупному проприетарщику.
> У вас везде враги вашего режима в голове мерещатся. Попейте таблеточки.Странно. Мерещатся мне, а минусомет в качестве "последнего довода" расчехлил подлизыватель. От оно чЁ, Михалыч!
ЧСХ - аргументов к #60 так и не последовало, только вопли оправдывания и смузихабрабные минусики. Так держать!
В обсуждении такого не было.
>минусометМного чести. Таблеточки всё же пропейте. Я автор тех комментариев и поставил не более одного раза минус.
>>минусомет
>>аргументов к #60 так и не последовало, только вопли оправдывания и смузихабрабные минусики.
> Много чести.А, ну да - не царско-анонимное это дело, аргýменты приводить.
> Таблеточки всё же пропейте. Я автор тех комментариев и поставил
> не более одного раза минус и у меня СОВСЕМ НЕ ПРИГОРЕЛО, СЛЫШЫШ!!
> Бла-бла.Т.е. по теме компетентности разрабов и проч - не будет ничего. Яснопонятно.
Лол, а железо вы в расчет не берете? Или у вас на разном железе программы и их алгоритмы работают совершенно идентично?
так погодьте.. скдя по новости гугл уже написал это всё и уже использует на своих серверах, а сейчас начали готовить патчи для коммита всего этого в мэйнстрим ядро..
> На этом месте паслись "зелёные нити" (полная х...ь как концепция, IMO)
> - во многие языки тянут coroutines (\equiv "зелёные нити");Да в этом все и дело - удобно реализовать сопрограммы без поддержки языка не вышло, а поскольку в божественной нерасширяемой идеальной сишечке поддержки нет, то и прижиться они не могли, а очень бы пригодились например в микроконтроллерах вместо гигантских конечных автоматов.
Привет поколению Z!Вы язык программирования с архитектурой процессора(ов) в запарке не попутали?
Бумерам привет.При чем тут архитектура? Для преобразования сопрограммы в конечный автомат:
http://dunkels.com/adam/pt/expansion.html
нужны особые архитектуры?
Зумерок, прекращай читать инвалидов умственного труда.
Автор uIP - инвалид умственного труда? Окей, бумер. Гиганты мысли с опеннета поражают.
Реализация tcp/ip под микроконтроллеры - святой грааль программирования? Окей, зумер, читай кого хочешь.
Если я правильно понимаю, то вы всё время в сторону программирования на baremetal подмигиваете.Так это вообще здесь не причём. Нет MMU, нет кэшей, нет операционки --- нет понятия kernel space/user space. Т.е. к изначальной теме никак не относится.
В "нерасширяемой сишечке" эти твои корутины делаются на макросах препроцессора.https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
Я знаю, пользоваться этим невозможно. Сравни с современными async/await.
Ну, тем не менее, подход Саймона Тэтхэма даёт рабочие корутины (утверждалось, что их невозможно реализовать совсем в сях, кроме как руками - я привёл контрпример). А async/await как по мне - вреден, ибо большинство смузипрогеров даже не вникает в то, как это работает. Типа, о - крутая штука для "многопоточности". А что там творится под капотом и как это реализовано (скажем, что там оно разворачивается в конечный автомат) - даже не догадываются. Реально есть кадры, которые на полном серьёзе считают, что корутины - это про мультитрединг.
Тут нужны оговорки. Первое это различать три вещи:
1. Корутины
2. Протопотоки
3. ФиберыТо, что ты показал не юзабельно, т.к. не используется одна важная инструкция современных процессоров -- JMP (b для ARM). Тут пример без jmp, но это, имхо, также из серии сделал-по-приколу, но более юзабельно чем то, что ты показал: https://github.com/spc476/C-Coroutines
>А async/await как по мне - вреден, ибо большинство смузипрогеров даже не вникает в то, как это работает.
>Реально есть кадры, которые на полном серьёзе считают, что корутины - это про мультитрединг.Если речь про async/await из C#, то там действительно они работают в режиме многопоточности. Это происходит просто потому, что операция await применяется к конкретному потоку (который заранее создан встроенным планировщиком) и не избирается автоматически для main-потока. И вообще, в C# нет корутин в юзерспейсе, равно как и файберов, хотя были реализации на сишных/плюсовых либах.
В других ЯП, корутины, основанные на jmp, можно оборачивать в конкретный поток, чтобы избавиться от ожидания операций с блокирующими доступом. В частности, контейнером для корутин могут быть форкнутые процессы.
Вывод, если ты смеешься над другими и точно знаешь нижележащую реализацию, то ты молодец. А если ты не знал сказанного выше, тогда мы посмеемся над тобой )
> В "нерасширяемой сишечке" эти твои корутины делаются на макросах препроцессора.Ты не смотрел, что по ссылке? Или просто не едал ничего слаще морковки?
> https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
> So now we have this monstrosity, let's rewrite our original code fragments using it.
int decompressor(void) {
static int c, len;
crBegin;
while (1) {
c = getchar();
if (c == EOF)
break;
if (c == 0xFF) {
len = getchar();
c = getchar();
while (len--)
crReturn(c);
} else
crReturn(c);
}
crReturn(EOF);
crFinish;
}
А что? Там должен быть async/await, выблёвывающий смузи?
Статические переменные внутри функции? Не велели такого отцы-основатели
> полная х...ь как концепция, IMOСразу понятно что вы не программист. Но спасибо за исторический экскурс.
https://ru.wikipedia.org/wiki/C10k
Зато люто плюсуют. 4 месяца не могли понять, а потом ответ оказался прост. Какая-то фантастическая история по мне.
А еще, как обычно: в Гугле одни идиоты (причем, заметьте, со всего мира), все здравые ребята здесь собрались: ишь, те изобретают велосипед заново, и даже не догадались подумать об очевидной вещи как %s.
> А еще, как обычно: в Гугле одни идиоты (причем, заметьте, со всего
> мира), все здравые ребята здесь собрались: ишь, те изобретают велосипед заново, и даже не догадались подумать об очевидной вещи как %s.Здравые ребята реалистично не считают себя Гуглом, а свои сценарии использования - схожими с гугловскими.
И основываясь на опыте предыдущих, в том числе и "академически верно" проработанных реализаций, закономерно ждут подвох для всех тех, кто не является Гуглом.
> 4 месяца не могли понять, а потом ответ оказался простРебята грамотные были. Сами и задались вопросом: "какого х...а сильно более простая реализация на характерных задачах так выиигрывает? Не упустили ли чего?". Пошли измерять/сравнивать. Потом пошло в news/ML, была публикация (ACM? --- не помню). Потом отдали приближённым, потом в пред-релиз (т.н. "модель T2"). Получилось: по практическим результатам T2 выглядела сильно лучше. В вырожденных случаях T2 не проигрывала основной модели, а в ряде практически значимых сценариев --- сильно выигрывала.
Таки да, на javascript не пишу.Ссылка-то эта к чему? Риди бога, ткните в меня реализацией C10k на setjmp/longjmp! А то так в неведении и помру.
https://ru.wikipedia.org/wiki/%D0%A1%D0%...
> В Linux'е Линус очень долго вообще отказывался делать поддержку нитей ядром. На этом месте паслись "зелёные нити" (полная х...ь как концепция, IMO). Но после большого успеха модели 1:1 у Sun, он быстро сотворил модель 1:1 в Linux'е.Всё дело в языка. Что для сишечки бессмысленно, сложно и просто ресурсы на ветер, то для жабаскрипта естественно как дыхание. Даёшь поддержку жабаскрипта (и прочих коллбек-ориентированных языков) на уровне ядра!
В js вообще нет нитей - он однопоточен. Главное встрять со своим комментарием про "любимый" язык?
У всех предыдущих подходов к N:M была одна общая болезнь: работа с диска. Оно блокировало «кернельный» тред, то бишь, один из M планировщиков целиком. На обработку «пользовательских» N-1 тредов оставалось M-1 шедулеров. Соответственно, если мы имеем нагрузкой базу данных, которая общается с диском много и одновременно, то очень быстро все M шедулеров оказывались в ожидании диска, а N-M тредов оказывались не удел.Первой (из общедоступных) правильный подход реализовала Go: когда шедулер-тред встаёт в сискол, она порождает новый тред.
При наличии подсистемы io_uring, все становится ещё намного проще: поход на диск перестаёт быть блокирующим. Ну и, в ядре то оно всю жизнь было асинхронным, просто не было доступного апи.
Вы посмотрите презентацию, они как раз упоминают враперы над блокирующими вызовами.
> Первой (из общедоступных) правильный подход реализовала Go: когда шедулер-тред встаёт в сискол, она порождает новый тред.Если это так (я не знаю), то всё просто зашибись: мы попросили новую страницу памяти, а нам в ответ пытаются добавить новую единицу планирования (со всем ворохом ресурсов, привязанных к ней, в т.ч. и с выделением тучки страниц). Идея перекликается с GC в Java.
> При наличии подсистемы io_uring, все становится ещё намного прощеС уриной пока всё тоже не слава богу:
"io_uring is currently like kqueue on OS X - it works with "important" file
types, but it fails as generic mechanism, and there is no way to detect what
will work or not, so workarounds are essentially impossible."
>В Linux'е Линус очень долго вообще отказывался делать поддержку нитей ядром. На этом месте паслись "зелёные нити" (полная х...ь как концепция, IMO). Но после большого успеха модели 1:1 у Sun, он быстро сотворил модель 1:1 в Linux'е.Забываем реализацию M:N со стороны IBM для Linux?.. а еще история...
Была попытка использования такой технологии в ядре NetBSD. Называлась Scheduler Activations (https://en.wikipedia.org/wiki/Scheduler_activations). Разработчики долго с ней боролись и в итоге забросили в пользу обычной 1:1.
Но "технологическое отставание" все равно у линукса. Смотри не перепутай.
Э.. а я про Linux ничего плохого не сказал, и про *BSD тоже. Это был исторический экскурс. Прошу прощения, что это Вас так затронуло.
2003: в NetBSD появляются Scheduler Activation
2008: переписывают поддержку Scheduler Activation для совместимости с 1:1
2020: "Google начал открытие реализации модели потоков M:N" для Linux
Действительно, кто же тут отстающий?
> Но "технологическое отставание" все равно у линукса.Молодец, все верно подметил!
https://www.freebsd.org/cgi/man.cgi?query=kse&apropos=0&sekt...
> kse -- kernel support for user threads
Overview
Traditionally, user threading has been implemented in one of two ways:
either all threads are managed in user space and the kernel is unaware of
any threading (also known as "N to 1"), or else separate processes shar-
ing a common memory space are created for each thread (also known as "N
to N"). These approaches have advantages and disadvantages:User threading Kernel threading
+ Lightweight - Heavyweight
+ User controls scheduling - Kernel controls scheduling
- Syscalls must be wrapped + No syscall wrapping required
- Cannot utilize multiple CPUs + Can utilize multiple CPUsThe KSE system is a hybrid approach that achieves the advantages of both
the user and kernel threading approaches. The underlying philosophy of
the KSE system is to give kernel support for user threading without tak-
ing away any of the user threading library's ability to make scheduling
decisions.
> September 10, 2002
> September 10, 2002Ну не особенно впечатляет...
Пока линукс и фряха занимаются спором у кого длиннее...А в NetBSD уже тесты уже делали в 90-х...
An Implementation of Scheduler Activations on the NetBSD Operating System
http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa....There are two goals of examining the performance of the scheduler activations system. The first is determining whether the added complexity of having scheduler activations in the kernel hurts the performance of ordinary applications. The second is comparing the performance of the resulting thread system with existing thread systems to demonstrate the merits of the scheduler activations approach.
The first measurements were done with the HBench-OS package from Harvard University [3]
[3] A. Brown and M. Seltzer.
Operating system benchmarking in the wake of lmbench: A case study of the performance of NetBSD on the Intel x86 architecture.
In Proceedings of the 1997 ACM SIGETRICS Conference on Measurement and Modeling of Computer Systems, pages 214-224, ___1997___.
1997 (!)Все идеи и драфты за авторством ребят из Wasabi Systems в 90-х (сейчас этой конторы нет, но костяк кодеров остался до сих пор в NetBSD). Так что все ваши фрибсд, айбиэмы, ораклы и прочее пролетают как фанера над Парижем.
а вообще.... ...scheduler activations have been implemented for research purposes in Taos [1], Mach 3.0 [2]... and adopted commercially in Digital Unix [5] (now Compaq Tru64 Unix)...
Compaq Tru64 Unix, карл... чуть позже и солярка заблистала... Так что эти ваши линуксы, фряхи, опенбзд уберите в сторону... тут правит балом netbsd и wasabi Systems...
>> September 10, 2002
> Ну не особенно впечатляет...
> Пока линукс и фряха занимаются спором у кого длиннее...
> А в NetBSD уже тесты уже делали в 90-х...
> In Proceedings of the 1997 ACM SIGETRICS Conference on Measurement and Modeling
> of Computer Systems, pages 214-224, ___1997___.
> 1997 (!)По ссылке не ходи, на SEE ALSO
SEE ALSO
rfork(2), pthread(3), ucontext(3)Thomas E. Anderson, Brian N. Bershad, Edward D. Lazowska, and Henry M.
Levy, "Scheduler activations: effective kernel support for the user-level
management of parallelism", ACM Press, ACM Transactions on Computer
Systems, Issue 1, Volume 10, pp. 53-79, February 1992.
не смотри, пиши про невпечатления.> Compaq Tru64 Unix, карл... чуть позже и солярка заблистала... Так что эти
> ваши линуксы, фряхи, опенбзд уберите в сторону... тут правит балом netbsd и wasabi Systems...Ну-ну
https://www.smalltechnews.com/archives/23495
> Netflix, which previously pushed for video streaming to reach 200Gb/s on
> Intel Xeno and AMD EPYC servers, has finally managed to reach 190Gb/s and
> found that AMD EPYC Naples/Rome servers have the potential to double the potential for up to twice as much as Intel.
> По ссылке не ходи, на SEE ALSO
> 53-79, February 1992.Баш на баш.
Nathan J. Williams
Wasabi Systems, Inc.
nathanw@wasabisystems.comThe work is based on the scheduler activations kernel interface proposed by Anderson et al. [1] for user-level control of parallelism in the presence of multiprogramming and multiprocessing.
[1] Thomas E. Anderson, Brian N. Bershad, Edward D. Lazowska, and Henry M. Levy.
Scheduler activations: Effective kernel support for the user-level management of parallelism.
In Proc. 19th ACM Symposium on Operating System Principles, pages 95-109, 1991.__1991__, Карл.
> не смотри, пиши про невпечатления.
С годами обделались, решили перейти на другие темы? Ну что же.
Netflix optimizes FreeBSD’s network stack to more than triple performance on AMD EPYC
November 25, 2019__2019__, EuroBSD 2019 conference.
2019-й, Карл. Ещё бы из будущего написали, года эдак из 2095-го. Мол смотрите какая прогрессивная FreeBSD.
Если решили сменить тему и в ссылки поиграть. Ну вот рандомная ссылка в стиле "у меня всё равно больше".
http://blog.netbsd.org/tnf/entry/the_strongest_kaslr_ever
Просто надо смириться - NetBSD технологический флагман, и из нетки годами все кому ни лень рипали идеи (линукс, фряха, опёнок и тп). NetBSD тестовый, академический полигон. Тут нет ничего необычного... Про крутые программисты там сидят и пишут для души... А этот ваш продакшн утаскивает идейки из нетки, обкатывает их...
ps а вообще конечно обидно за фряху... раньше была популярной системой, а сейчас зайдёшь в темы про фряху и видишь этот вечный пример про нетфликс или zfs... убогая __нищета__ аргументов, как говорится...
> __1991__, Карл.
>> не смотри, пиши про невпечатления.
> С годами обделались, решили перейти на другие темы? Ну что же.Сам что-то придумал, сам что-то доказал.
> Netflix optimizes FreeBSD’s network stack to more than triple performance on AMD
> EPYC
> November 25, 2019
> __2019__, EuroBSD 2019 conference.
> 2019-й, Карл. Ещё бы из будущего написали, года эдак из 2095-го. Мол
> смотрите какая прогрессивная FreeBSD.Да-да. 2019 год, 200Gbp/s. Где там правящая балом нетбзд и wasabi systems?
> Если решили сменить тему и в ссылки поиграть. Ну вот рандомная ссылка
> в стиле "у меня всё равно больше".
> http://blog.netbsd.org/tnf/entry/the_strongest_kaslr_ever
> Просто надо смириться - NetBSD технологический флагман, и из нетки годами всеСам задал тему
>> Compaq Tru64 Unix, карл... чуть позже и солярка заблистала... Так что эти
>> ваши линуксы, фряхи, опенбзд уберите в сторону... тут правит балом netbsd и wasabi Systems...сам слился, сам обвинил в смене темы. Красота!
> ps а вообще конечно обидно за фряху... раньше была популярной системой, а
> сейчас зайдёшь в темы про фряху и видишь этот вечный пример
> про нетфликс или zfs... убогая __нищета__ аргументов, как говорится...Зато надежно конфузит смузихлебов и перепончатых любителей "тперь уже точно совсем как в венде, только нахаляву!" - возразить им нечего.
> Баш на баш.Кстати, да
>> Thomas E. Anderson, Brian N. Bershad, Edward D. Lazowska, and Henry M. Levy, "Scheduler activations: effective kernel support for the user-level management of parallelism", ACM Press, ACM Transactions on Computer Systems, Issue 1, Volume 10, pp. 53-79, February 1992.
> The work is based on the scheduler activations kernel interface proposed by
> Anderson et al. [1] for user-level control of parallelism in the
> presence of multiprogramming and multiprocessing.
> [1] Thomas E. Anderson, Brian N. Bershad, Edward D. Lazowska, and Henry
> M. Levy.
> Scheduler activations: Effective kernel support for the user-level management of parallelism.
> In Proc. 19th ACM Symposium on Operating System Principles, pages 95-109, 1991.
> __1991__, Карл.Кроме циферок - неплохо бы и названия и авторов прочитать.
> С годами обделались,
Почти все верно, только не с годами, а с авторами и статьей. Ну и, судя по всему, не я.
> Просто надо смириться - NetBSD технологический флагман, и из нетки годами все
> кому ни лень рипали идеи (линукс, фряха, опёнок и тп).Идеи в IT видите ли рипают все друг у друга понемногу. Тот же clone() в Linux значительно более мощный сискол нежели просто реализация fork и execve и позволяет намного больше. И это вроде аж частично с plan9 было слизано.
А чтобы называться флагманом... а какие там собственно технологии в юзабельном виде есть? Ну хоть файловая система, чтоли, какая лучше чем у других? Или какие-то еще уберполезные по жизни фичи, которых у других нет? Ну там виртуализатор, круче только яйца? Система контейнеров, стройная и изначально заложенная в дизайн ядра? Или, ..., чего?
> NetBSD тестовый, академический полигон. Тут нет ничего необычного...
Взаимоисключающие параграфы. Это противоречит заявлениям про флагманов. Извините, большая часть лабораторных установок разбирается и списывается в утиль. И лишь очень небольшой процент доводится до ума, и выглядит в пригодном к применению виде несколько иначе нежели на столе в лабе.
> Про крутые программисты там сидят и пишут для души...
И даже совсем не на гранты вон тех проприетарщиков? :)
> А этот ваш продакшн утаскивает идейки из нетки, обкатывает их...
А знаете, компьютер пригодный для продакшна - штука все-таки хорошая. Потому что в конечном итоге для дущи - это прекрасно. А еще прекраснее если всем этим потом еще и пользоваться для решения практических задач можно, а не только как экспонат на музейную полочку - мол, концепт крутой, но чего-то не взлетел. А то круто получается, рассказывать про душу, под дуалбут в пробэкдореную блобосистему то.
> про нетфликс или zfs... убогая __нищета__ аргументов, как говорится...
"Хода нет - ходи с бубей".
> Просто надо смириться - NetBSD технологический флагманДа уже все смирились, не волнуйся! Вон NetBSD - на большинстве северов, заняла топ-500 и к доминированию на десктопах подбирается. Всё-таки не зря там профессионалы пишут.
Увы, уже давным-давно не технический флагман и сама тащит в себя с линукса.
> Все идеи и драфты за авторством ребят из Wasabi Systems в 90-х (сейчас этой конторы нет, но костяк кодеров остался до сих пор в NetBSD). Так что все ваши фрибсд, айбиэмы, ораклы и прочее пролетают как фанера над Парижем.Почему пролетают-то? "Костяк кодеров из Wasabi Systems" выкинул M:N из NetBSD и теперь там 1:1 как в этих ваших линуксах, фряхах и опенбзд? В чём успех-то?
(местные нетбздшники что-то совсем уже поехали)
> В чём успех-то?разработали, написали код, протестировали, сравнили, провели тесты... чем не успех - исчерпывающая разработка проблематики? это тоже своеобразный технологический успех. я считаю - абсолютный успех... и теперь в 2020-м году гугел что-то там открывает и тестирует... какие-то графики... ох лол... либо слоупоки, либо новомодные смузихлёбы...
> что-то совсем уже поехали
ой да ладно... это вы поехали... или косите мол под ничего не понимающего...
>гугел что-то там открываетИсходный код открывает. Заголовок переведённой статьи провокационный и не отражает суть.
Да какая разница если они всё забросили и все полимеры пр*с**ли?В бсде вообще ленивые смешные люди сидят которым на ОС и технологии плевать, у них свои какие-то абскурные задачи, на половину академические (пример Беркли) наполовину чисто коммерческие (фаерволы гонять)
> Была попытка использования такой технологии в ядре NetBSD. Называлась Scheduler Activations
> (https://en.wikipedia.org/wiki/Scheduler_activations). Разработчики долго с ней боролись
> и в итоге забросили в пользу обычной 1:1.В соплярисе и фре тоже было и тоже забросили.
Если я правильно понимаю, в винде такое тоже есть и называется fibers (https://docs.microsoft.com/en-us/windows/win32/procthread/fi...). Появилось в хр и я ни разу не видел, чтобы это где-то использовали. Что-то мне кажется, с линуксной реализацией будет так же
Да, причем судя по описанию задумано нормально. Создать потоки для утилизации всех ядер и в каждом крутить свой цикл для утилизации ядра.
Используется редко т.к. надо заново учится программировать на событийных машинах. Намного проще когда у тебя есть простыня последовательно выполняемого кода. Без всяких подводных камней.
> Создать потоки для утилизации всех ядер и в каждом крутить свой цикл для утилизации ядра.Если задача --- именно утилизировать ядро, то так, наверное, и надо.
Но можно было бы и что-то полезное делать...
Fibers, оно же coroutines - это другое. Грубо говоря, это кооперативная многозадачность, т.е. несколько задач, выполняющиеся в *одном потоке* могут переключаться между собой. Из этого вытекают и основные болячки этого подхода, как неработающий TLS, проблемы с блокировкой потока и проблемы с отладкой.В сабже речь идёт о реальных потоках, которые благодаря FUTEX_SWAP получают возможность быстро переключаться между собой. При этом, будучи настоящими потоками, для них работают TLS, их можно блокировать и они могут выполняться параллельно, если есть такая возможность.
По сути, новость вводит в заблуждение, т.к. модель потоков в Linux не меняется. Просто добавляется еще одна операция, которая позволяет повысить эффективность переключения между потоками.
Ну, вместо TLS можно использовать FLS, ино дело, что сразу теряешь языковую поддержку - __declspec(thread) и thread_local сразу становятся не про нас, ну и библиотечные вызовы, где TLS используются (иногда неявно - см. errno) идут лесом.
Интересно кто первый угробит линукс - гугл или микрософт?
комментаторы опеннет
Но ведь комментаторы никакой работы, кроме комментариев не производят. Линуксу нечего бояться.
>Но ведь комментаторы никакой работы, кроме комментариев не производят. Линуксу нечего бояться.Даже окружающую среду не портят, в отличие от гномеров :)
> Даже окружающую среду не портят, в отличие от гномеров :)Как это? Они производят углекислый газ и даже метан. Это парниковые газы!!!
Ну как же не производят...
Они дурно влияют на неокрепшие умы
Либерасты угробят.
Ведь M:N — это зашифрованное MAN. Это явный сексизм и требуется гендерно-нейстральный термин.
>Ведь M:N — это зашифрованное MANMaster и Niger, же..
Ты прав, так намного очевиднее.
> Либерасты угробят.Тоталитарные уродц придумали на этот случай отличное решение: нет софта - нет проблем! А если еще инженерию слить до уровня землянок - вообще становится зашибись.
Во бомбит, а. Пока что по очкам либеральные негромакаки уделывают. Иди, попробуй им скажи в лицо что важны все жизни.
> Во бомбит, а. Пока что по очкам либеральные негромакаки уделывают. Иди, попробуй
> им скажи в лицо что важны все жизни.Иди вон в команду Шигорина линух на брусы пилить, там тебе покажут всю мощь и крутизну подходов, чтоли. Сможешь проникнуться всей прелестью из первых рук, так сказать.
Бла-бла-бла. Пока ты языком мелешь, очередной ниггер убивает очередного белого. Езжай туда скорее. этим белым можешь быть ты. Докажи делом свои слова, тряпка.
> Бла-бла-бла. Пока ты языком мелешь, очередной ниггер убивает очередного белого. Езжай туда скорее.Эм, ну вообще я в европы как-то перебираюсь. Потому что наслаждаться росиянскими гестапцами до гроба мне западло. Но вообще, если представится удобная оказия - я и к линчевателям негров согласен.
> этим белым можешь быть ты.
А я вот и отличные от твоей тупой пропаганды варианты видел - например фоточки, где негры и белые одной стеной, за одни слоганы. И я даже нахожу что слоган "black lives matter" меня вполне устраивает. Более того, собственно, после известных действий полиции я этих граждан вполне понимаю в их недовольстве такими действиями представителей государства. Только россияне могут дохнуть миллионами и не возмущаться. А вот даже негры не настолько глупые по жизни и вот так делать все же не собираются. А за такую феерическую тупизну, видите ли, отливается. На уровне демографии и национального состава уже попросту. Это конечно можно игнорировать, но когда в 6 утра тупо ни 1 русского слова на улице... на мой вкус это уже давно превысило все мыслимые рамки. Особенно умильно когда про это вот вещают в контексте европ, но ни звука про то что крупные города стали каким-то Ташкентом у себя. Вот европейцы в этом как-то честнее и рациональнее, они в зеркало иногда смотрятся, вместо перевода стрелок.
> Докажи делом свои слова, тряпка.
Когда я что-то говорю, это обычно худо-бедно обеспечено технически "в фоне". Так что насчет тряпок мы будем посмотреть.
>Интересно кто первый угробит линукс - гугл или микрософт?Поттеринг и гномеры.
Стараниями таких помощников типа мс и гугля скоро переключение контекста будет происходить через http-запрос к центральному серверу (switchto.googleapis.com)
https, а не http
Вот и выросло поколение, считающее HTTPS отдельным протоколом.
У тебя глюки? Тут никто такого не писал =)
Ыыы, жжошь!
Это будет делать systemd-networkd
> Ценой данного варианта является большое усложнение реализации планировщика потоков в пространстве пользователя и необходимость в механизмах согласования действий с планировщиком ядра.Всё начинается как с системд -- сматрите, всё в разы быстрее!!11
1:1 вроде очень лаконичная модель, зачем мудрить?
Затем, что по-настоящему низкоуровневый и важный код пишется не для того чтобы программисты любовались его лаконичностью, а для машины и конечных пользователей. См. последний абзац.
насколько же велики эти накладные расходы по переключению контекста?
Таки может новость прочитаете? Там даже большими графиками нарисовано.
Такие статья не пишет, как это "добро" отражается в производительности реальных многопоточных алгоритмов и какой она даёт выигрыш.
Реальные многопоточные приложения очень разные. Нет какой-то одной модели, которая позволит оценить влияние и будет верна для всех. Тебе предлагается думать своей головой: подумать о том, как работает твоё приложение, насколько часто оно переключает контексты, и как оно может выиграть от снижения стоимости переключения на порядок. Вообще, лучше даже не думать, а взять и померять частоту переключений контекстов в своём приложении и посчитать.
Вы когда-нибудь видели по-настоящему большой виртуализированный астериск?
24 ядра, но по 2.4GHz, 32ГБ памяти... что-нибудь в таких размерах да еще и с кучей скриптов и тяжеловесных модулей вроде CEL/CDR кучей ARI-стазисов и еще и внутренних AGI-подпрограмм.Может так случиться, что накладные расходы на переключение контекста приведут к полной деградации сервисов, при утилизации 20-40%. Скажем так. Если у вас 14000 переключений контекста на 1 ядро - конец близок. Добавьте накладные расходы на виртуализацию и каждый CS становится золотым!
Да-да. Переключение контекстов в системе может быть основной и центральной метрикой по загрузке (не CPU%) в особых случаях! Asterisk не единственный такой, есть еще Citrix Virtual Apps and Desktops (бывшие XenApp/XenDesktop). И если службы терминалов достаточно просто горизонтально смасштабировать по какому-то принципу, то с Asterisk ситуация может быть очень разная.
Просто приведу пример с *, вдруг кому-то пригодится:
1. Избавиться от лишних кодеков. У вас должен быть один кодек G711 a-law, тот который стандартизирован для РФ.
2. Если у вас есть требования на G711 μ-law или T.38 вам нужно от них избавиться по причине того, что сейчас уже 2020-й год, а факсы - остались в 20-ом. Для людей которые любят традиции и жизнь прошлым, можно поставить gateway T.38 -> e-mail а исходящие факсы запретить административно. Накрайняк, можно и наоборот замутить, но это решение крайне специфично для конкретной инфраструктуры... вообще если вы работаете в компании, которая хочет отправлять факсы в 2020-ом году, то это повод искать новую работу.
3. работа с ISDN E1 и SS7 должна производиться на отдельном железе, которое нужно притранковать. Оно же вам должно всё закодировать через g711a.
4. Избавьтесь от IAX. Мат-фильтр opennet не пропустит комментарий, если я буду объяснять, что я думаю об этом протоколе. Ограничимся тем, что оно не должно было существовать изначально. Оно порождает не только проблемы с производительностью, но и с качеством.
5. CHAN_SIP должен гореть в соседнем котле рядышком с IAX2, переход на PJSIP увеличивает реальную утилизацию на ~30-40% при том же количестве контекстов. Деградация снизится, будет расти эффективность в виду внетренней архитектуры * и как он работает с потоками.
5. Регистрация - это слабое место PJSIP. Увеличение утилизации в одном случае (звонок) даёт рост КПД, в другом случае (регистрация) выливается в рост потребления ресурсов при старте. Перезагрузка сервера с 4000 пользователей может и снова его уронить. Вынос регистрации на отдельное железо решает проблему. И совсем не обязательно, чтобы там был именно *. С этой задачей превосходнос правится kamailio.
6. AGI - это дорого и жирно. Нужно сеcть с разработчиками и пересмотреть архитектуру решения либо в сторону максимального перехода на ARI либо, если не получается, написать небольшой сервер приложений на любом языке программирования, выбросив поганые python-скрипты, заменяя их веб-сервисами (можно и на python :)
7. Когда монстр похудел, пора задуматься о виртуальном сетевом адаптере. E1000/E1000E - на помойку сразу. В идеале адаптер должен подаваться через SR-IOV. Эти виртуальные адаптеры также порождают огромные накладные расходы по контекстам. Если в арсенале нет ничего лучше vmxnet - поставьте нормальный гипервизор hyper-v или KVM.
8. Снизьте накладные расходы на виртуализацию. У вас должен быть 1 сокет с фиксированным количеством памяти без всяких поползновений. Приоритеты по частотам у каждого настраиваются по-своему. Strict NUMA вам в помощь вплоть до привязки конкретных ядер конкретных камней.
9. Дальше вы включаете мониторинг и меряете переключение контекстов сутки. Относительно ПИКОВОГО значения рассчитываете количество ядер на каждые 14000 переключений. Докидываете и продолжаете следить.> насколько же велики эти накладные расходы по переключению контекста?
я видел и 470 000 CS через vmstat
> Вы когда-нибудь видели по-настоящему большой виртуализированный астериск?Писать программы для виртуальной машины, запихивать все эти программы в разные виртуальные машины... "Ядро виновато, оно медленно всё переключает!".
> "Ядро виновато, оно медленно всё переключает!".Это вы сказали. При чем ты ядро. Если прочитать комментарий, то станет понятно, что дело в архитектуре. Кроме того, если бы вы поизучали, что такого особенного в многопоточных мультимедийных приложениях, то поняли бы почему они подвержены проблемам переключений контекстов. Срыв покровов, на голом железе ситуация примерно похожая.
>Срыв покровов, на голом железе ситуация примерно похожая.нет.
никто не гоняет нагруженные приложения в ритуалках. спросите хотябы у держателей серверов ммо игр.
во-первых, да такая же, но в разительно меньшей степени.
во-вторых, вы живете в вымышленном мире, где все работает исключительно по инструкции, производится академический анализ архитектуры приложения и нет никакого "раз, два и в продакшн". Если бы ваш воображаемый мир был реальностью, у меня бы вообще не было заказов на исправление подобной ерунды.
Реальность не только в том, что люди так делают, а еще и в том, что баран^W заказчик может иметь свои обстоятельства, которые аргументируются гуманитарно, а не технически и, вообще, выбирайтесь из своего максималисткого мира грёз. Начните хотя бы с отказа от ммо игр, честное слово.
> Вы когда-нибудь видели по-настоящему большой виртуализированный астериск?24 ядра, но по 2.4GHz, 32ГБ памяти... что-нибудь в таких размерах да еще и с кучей скриптов и тяжеловесных модулей вроде CEL/CDR кучей ARI-стазисов и еще и внутренних AGI-подпрограмм.
Мы видели и видим не такую слабенькую технику.
> Мы видели и видим не такую слабенькую технику.Это комментарий в стиле "у меня болшэ"? Ну ок, чо, держите нас в курсе. Нам всем очень интересно (на самом деле нет). Комментарий был ответом конкретному человеку на конкретный вопрос. Но вот пришел ты, опой нюхаешь цветы.
Если вы имели ввиду "есть специфичные системы где очень много процессов (как единиц планирования) и переключений контекстов ядро/пользователь очень много", тоэто "специфичные системы"; проблема эффективных менеджеров --- попытка решать
довольно специальные задачи софтом "общего назначения" (и программистами общего назначения),
а если получается плохо, то будем корёжить софт "общего назначения" под спец. задачи.А для совсем сильно спец. задач и кремний спецально под эти задачи есть.
Ага, осталось только вывод сделать из собственного же комментария. Ближе к делу!
Я сначала хотел откомментировать, но потом понял, что этот бесценный опыт получен не просто так: из всех возможных вариантов решения везде были выбраны ошибочные. А потом героически с результатом этого действа боролись, откуда сий опыт и взят.
У меня такой дома стоит
И у меня.
> Вы когда-нибудь видели по-настоящему большой виртуализированный астериск?
> 24 ядра, но по 2.4GHz, 32ГБ памяти... что-нибудь в таких размерах да
> еще и с кучей скриптов и тяжеловесных модулей вроде CEL/CDR кучей
> ARI-стазисов и еще и внутренних AGI-подпрограмм.очень доходчиво.спс
а с фрисвич практика параллели?
При этом fibers из FreeBSD выпилили, в NT их практически никто по назначению не использует, а про thread pool некоторые и не знают.
Точнее сказать никто не использует в НТ-е без злого умысла, а вот вирусня помню очень даже активно юзала нитки
Например, волокна (fibers) применяют для реализации сопрограмм. Зловреды именно что нитки (thread) задействуют, инжектируя код в чужое адресное пространство.
Фиберы юзали, когда их ав-движки еще толком не разбирали.
А инжекты в (приостановленные) потоки уже позже появились.
Давайте внесём ясность. Машинный код располагается в ячейках памяти, а те - в адресном пространстве (АП). АП принадлежит объекту "процесс". Сам процесс в NT не исполняется, исполняются его потоки. Зловред копирует свою "полезную" нагрузку в АП браузера и создаёт там новый поток (каким образом -- дело десятое). Это и называется инъекция кода (инжект), соответственно -- в процесс. Это задача "что бы работало". Если перекрыть вектор атаки, отвалится масса г-на.А если фиберы применяли для надурить эвристику -- по-моему, эта задача называется "генерация исполняемого мусора"? Если запретить фиберы, зловреды особо не пострадают.
Да, опечатался, в приостановленный процесс, но для локальной эскалации. CreateRemoteThread вроде, потом это дело быстро прикрыли конечно.
Ничего не мешало навесить на фиберы полезную нагрузку, просто движки их не парсили. Мусор тут нипричем. Это вроде как с файловыми потоками в NTFS было. Security through obscurity.
> Да, опечатался, в приостановленный процесс, но для локальной эскалации. CreateRemoteThread
> вроде, потом это дело быстро прикрыли конечно.Там были ещё варианты. Вот что пишет специалист, первым разобравший Rustock.C:
"имеет в составе библиотеку, внедряемую в один из системных процессов ОС
Windows." https://www.drweb.ru/upload/56d8247826582537818c3a7de8949928...
т.е. явно без CreateRemoteThread, поскольку делал это из ядра.> Ничего не мешало навесить на фиберы полезную нагрузку,
То есть пропатчить код приложения-жертвы для вызова SwitchToFiber()? В таком случае возможно и непосредственно "нагрузку" врезать. Сама SwitchToFiber(), насколько помню, кроссплатформенно сохраняет регистры и ничего особенного не делает.
Это хорошо или плохо? Объясните пожалуйста ламеру.
Эти категории здесь ни при чём.Предложенное не пошло по совокупности факторов: выигрыш на характерных задачах был (если вообще был, мог быть и проигрыш) несущественным, программирование требовало более высокой квалификации/внимания/организации, сопровождение (поиск проблем, воспроизводимость, ...) усложнялось.
Если про fibers (coroutins там рядом), то программирование в кооперативной многозадачности --- довольно тяжелая вещь. В смысле --- тяжело программировать/отлаживать/сопровождать. Там очень много неявных ограничений на то, как и где этим пользоваться. Компиляторы косяки программирования в этой парадигме почти не ловят. Всё ложится на людишек, а это очень ненадёжный материал.
теперь линукс перестанет тормозить?
Сразу после того как весь софт на M:N потоки перепишут
конечно же на Расте
Это ж гугл. На go.
На JavaScript!
Будет тормозить в Н раз быстрее.
Ну давайте-ка честно: гугл за последние ГОДЫ не сделал ни-че-го хорошего! Пожалуй за последние лет 10.. Поэтому, даже из общих соображений понятно, что место этому на свалке :)
Ну зачем вы так? magic lantern вот неплохо получилась, например.
https://github.com/google?q=&type=source
Совсем ничего, да.
> Основным недостатком модели 1:1 являются большие накладные расходы на переключение контекста между ядром и пространством пользователя.А куда уйдут эти расходы при M:N?
Как компенсируются расходы при переносе клиентского процесса из одного ядра CPU на другое?
При 1:1 и N:1 поток ядра монопольно использует память.
M:N будет с разделяемой памятью, что на некоторых нагрузках может тормозить.M:N нужен для частных случаев. M:N в user space еще более частный случай.
> M:N нужен для частных случаев. M:N в user space еще более частный случай.Программисты на Go, имеющие M:N в user space уже несколько лет, смотрят на тебя с пониманием.
Хотя, GUI то нормального так и нет. Android, iOS - все побоку.
Так что да: backend services - это действительно частный случай. Такой маааленький частный случай.
"Возьмем N точек, нет, N мало - возьмем M." (c)
Расслабьтесь. Этот код уже апробирован в голанге лет пять так что включат в ядро легко
M:N же давно показал свою несостоятельность и выпилен отовсюду куда его пытались впилить.
Итак создаем проблемы, добавляя фичу долго и упорно с ними боремся. Удаляем фичу красиво аргументируя графиками и цифрами которые идеально подогнаны на частных случаях. Пол года можно при этом поплевывать в потолок получая деньги.
PS. Хотя хочется верить что гугл тока веб ломает, а не добрался и до линукса.
>Инициатива Google связана с открытием развивавшегося за закрытыми дверями API SwitchTo для ядра LinuxЗачем Гугл пихает в ядро своё говно? Пусть оно так и оставалось бы за закрытыми дверями?
Я чего то недопонял. Сначала все хипстеры у гугл в том числе тянули TCP в usermode и продвигали модели разработки свойственные микроядрам. Хвалили виртуальные машины, ядро которых по сути особое приложение. А теперь заявляют, что этот подход медленный и нужно вернуться к монолитам? Что дальше, WebAssembly в ядре вместо процессов, чтобы вообще контекст не переключать?
> WebAssembly в ядре вместо процессов, чтобы вообще контекст не переключать?Баян, это кто-то вроде уже даже накодил.
>Сначала все хипстеры у гугл в том числе тянули TCP в usermode
>Планирование и управление распределением потоков производится целиком в пространстве пользователяИ продолжают тянуть.
Я конечно все понимаю, но если в гошечке наклепать горутин и запустить все на одном ядре 15% производительности улетают. Вполне возможно что для гугла так лучше но явно это не для всех.
Вопрос имею: а вот вынос планировщика в юзерспейс - как оно концептуально с точки зрения безопасности? Какие будут мнения? И должен ли этот планировщик иметь рута или какую то, может, капабилитю будет достаточно?
Ничего личного, но это не вопрос, а набор слов из предметной области. На ответ тянула бы серия лекций из области "Теория Операционных Систем".
Ответ прост как 2 копейки: сделайте доброе дело, прекратите шарлатанство и профанацию с этой вашей Розалинукс, пока люди не пострадали.
> Ответ прост как 2 копейки: сделайте доброе дело, прекратите шарлатанство и профанацию
> с этой вашей Розалинукс, пока люди не пострадали.Смотрите, дети: классический пример нездоровой фиксации и фобий.
Это ты тот персонаж, которого ссылка на Пуфлера https://sun9-20.userapi.com/b8qwsxYAWkpKCMqlux_9f-uH0PVRsj1J... из Розалинукс бомбанула и вынудила отвечать на все подряд мои комментарии?Ничего личного к этим проходимцам в няшных чепчиках, но инфраструктура там слегка, эмм... скомпрометирована https://vk.com/video-33847957_456239489
Такую систему в просторечии называют "дырявой". Совпадение? Не думаю! (с)
Какая то странная реакция.
Не знать что-либо -- само по себе не плохо. Но когда неуч начинает продавать свою безграмотность, это не только аморально, но и опасно. Хорошо еще, если твой сайт ООО "НТЦ ИТ РОСА" https://vk.com/video-33847957_456239489 тупо ломанули ботом и за 2 дня до того, как вы узнали об этом из ВК, а не полгода назад, протроянив всех пользователей, включая гос.учреждения.
Ты какой то странный. К доктору ходить не пробовал? У меня нет никаких сайтов. Доброе утро.
Расскажи еще, что никогда в той шаражке не работал, не собеседовал и не трудоустраивал туда бестолочей (кого ты ещё можешь принять с "вопросами" из #82?), не учил г-на Потапова грамотно попрошайничать, создавая так называемое НКО (результаты деятельности которого вы изначально намеревались монетизировать) РОСПО. Напиши, что ты некий левый чел, который пишет с того же ника наивные откорячки с характерной стилистикой.
Да потому, что вопрос твой -- бред.Представь себе программу. Программа выполняет много операций, некоторые дольше, некоторые быстрее, некоторые блокируются в ожидании какого-то внешнего события. Классически эти операции упорядочивались программистом и выполнялись последовательно. Потом набор операций для выполнения стали разбивать на несколько потоков, каждый из которых был упорядоченным потоком операций. И упорядочивал опять же программист.
Но тогда же пилили "зелёные" треды: они позволяют программисту упорядочивать операции во много потоков, и потом в рантайме эти потоки будут перетасовываться в один поток -- это удобно тем, что программист может писать код работы с http-соединением как последовательный, но когда этот код заблокируется в ожидании свежих данных из сети, ядерный поток выполнения не заблокируется, потому как в юзерспейсе будет выполнено переключение "зелёных" тредов, и продолжит выполнятся поток, который не заблокирован.
В принципе, всё это было просто другим способом делать select/epoll: select/epoll прятались в библиотеке зелёных потоков, а программист писал, будто бы у него на каждое соединение свой собственный ядерный тред.
Но сочетать ядерные потоки с юзерспейсными сложно. Все попытки делать это в C разбивались об эту сложность. Тем временем функциональные языки потихоньку осваивали это дело. Гугл понаблюдал за ними, и запилил корутины в Go. Фишка в том, что программист комбинирует операции, задавая порядок выполнения, а потом рантайм эти операции раскидывает по ядерным потокам, выполняя что-то параллельно, а что-то последовательно.
Это очень упрощённая версия истории событий, но основной вывод отсюда: корутины и юзерспейс-многозадачность -- это разные способы для программиста выполнять те же самые задачи мультиплексирования ввода/вывода, то есть переупорядочивать операции, выполнять их по мере готовности данных, по возможности выполнять максимум операций параллельно на разных ядрах, и тп. Повышение или снижение безопасности может случится, если один из подходов больше способствует возникновению программерских ошибок, а другой меньше. Но... ты действительно хочешь об этом поговорить? Что-то мне подсказывает, что это не то, что тебя интересует. И поэтому я говорю тебе: вопрос твой -- бред. И поэтому ты получаешь минусы.
> Вопрос имею: а вот вынос планировщика в юзерспейс - как оно концептуально
> с точки зрения безопасности? Какие будут мнения?ИМХО - "никак". Это для удобства приложений с кооперативными корутинами или типа того. На работу ядра это не особо влияет, кроме того что некоторые операции - сильно дешевле. А секурити модель или способность ядра выпереть тред с проца это не отменяет. Просто в пределах того треда может еще быть некая кооративная дележка, которая НЕ ТРЕБУЕТ ЩЕЛКАТЬ ПОЛНЫМ КОНТЕКСТОМ, телепаться между юзером и кернелом и проч.
А ядро что, ему в принципе не обязательно знать как там внутри себя программа работает, оно энфорсит общие лимиты ресурсов и делает окончательный арбитраж. Тонкости того как именно прога теми ресурсами воспользуется в пределах лимитов - а какое ядру до этого дело?
Реально там основные сложности с другими вещами - там в работе были еще некие патчи затрагивающие смежные вещи и вот там есть определенные грабли. Но об этом есть в рассылке. Читайте.
Спасибо. Но я бы смотрел чуть по другому. Раз это юзерспейс процесс, то он, по идее, подпадает под лимитирование. И что там будет в случае перегрузки - предсказать сложно.
Было уже в Linux'е под именем NGPT, забросили где-то в 2003, перенеся в NPTL "лучшие части".```In 2003, IBM released the Next Generation POSIX Threads (NGPT), which offered substantial improvements over LinuxThreads. It improved support for the POSIX standard, and was notable for providing an M:N threading model in which M user-space threads are executed on N kernel threads, as opposed to Linux's traditional 1:1 model.```
Если речь о том что под Windows называется "нити" ( Fibers ) - то когда-то на Channel9-канале Mark Russinovich (было очень очень давно это) - рассказывал что в отладка ПО с нитями было похоже на АД и не рекомендовал их использовать. Точнее проблему с ними я не помню, но что-то со общими стеками и т.п.
Та нет там никаких проблем особенно если все отлажено и хорошо работает под капотом. А вот разрабтывать всякие языки вроде GOlang так для этого всякие Робы Пайки есть в Гугле =)
Планировщик должен быть на основе нейросети.
и блокчейна
обязательно с шифрованной арифметикой ключом 65536 бит
Can anything good come out of google?