это же синтетика :)

каждый их этих 10к (независимо от того как обрабатывается, конечно) испачкает как минимум по странице

не понял

кстати, страниц может быть вообще 1 (одна):

CPUs that do support 1GB pages:
Xeon E5620 (Westmere)
Core i5-4250U (Haswell, Mobile)

https://superuser.com/questions/710870/which-cpus-support-1gb-pages

А если переполниться - насрать.

ага, а можно вообще на все насрать и никакой полезной работы сервером не делать — еще лучше, и главное проще

Цитата, правда, от 2012-го года. Может что-то существенно улучшилось за прошедшее время.

Статья замеряет и делает выводы не о переключении контекста, а о переключении контекста и планировке.

Статьи начиная с 2004 года https://lwn.net/Articles/80911/ и документация https://www.kernel.org/doc/Documentation/scheduler/sched-domains.txt считают, что планировщик всё-таки старается привязывать потоки к CPU. Так что, видимо, процитированное утверждение было голословным.

Могли бы вы поделиться каким-нибудь бенчмарками на эту тему?

Патчей на линукс, позволяющих принудительно переключать контекст без вызова планировщика, сейчас нет в открытом доступе, из-за чего замерить это достаточно сложно. Тем не менее, у автора первоначальной статьи на гитхабе есть какой-то код, который занимается переключением контекста: https://github.com/tsuna/contextswitch

Если хотите и нечего делать в пятницу вечером, можем договориться о бенчмарке, чья методология устроит всех присутствующих, я напишу его реализацию на pthreads и boost::fibers, Вы сможете написать на зелёных нитях го, потом замерим разницу в работе.

Мне кажется, должно быть что-то вроде классического пинг-понга через socketpair(), но с некоторой обработкой процессором значения, пришедшего от второго треда (типа вычисления долгого bcrypt-хеша). Настаиваю на не использовании исключительно юзерспейсовых каналов коммуникации типа boost::fibers::channel, т.к. всё-таки изначально речь шла о сетевом взаимодействии, в котором должно участвовать ядро.

если у нас стек ну пусть даже 40Кб (с гвард-страницей), то это 10 страниц, а нитей у нас 10К, значит всего 100К страниц, это 400МБайт

Так мы же всё-таки можем обойтись без гвард-страниц и все стеки так же как и с еполлом аллоцировать в одной гигабайтовой странице.

А вы еще что за хрен с горы? Здесь анонимов-неадекватов и так перебор. Есть что сказать предметное, говорите. А испражняться в ослоумии не нужно.

переключения (обычно их называют системными вызовами) являются основным тормозом любого современного серверного приложения

Не верно. Хотя отчасти да, действительно в ситуации с ущербанскими сокетами у тебя проблема явно в переключениях.

По поводу твоего ответа. Я тебе советую следить за контекстом. И не врать. В рамках контекста говорилось, что «ДОПОЛНИТЕЛЬНЫЕ переключения» являются притянутым за уши свойством, а не переключения вообще.

Ну запускается системный тред, в него копируется образ запущенного процесса (по крайней мере та часть, которая подвержена изменениям). А образ этот - JVM. Получается каждый тред при создании копирует в себя образ JVM родителя? Или как?

Я с jvm не знаком, но не понимаю зачем так делать. Это же не скриптота без нормальных потоков.

По вашей логике у каждого потока будет свой GC, что, насколько я знаю, не так.

Если хотите и нечего делать в пятницу вечером, можем договориться о бенчмарке, чья методология устроит всех присутствующих, я напишу его реализацию на pthreads и boost::fibers

Я сам пользуюсь только C++ в последние годы. Да и до понедельника нужно написать порядочное количество документации, так что без меня.

ЗЫ. Думал, что есть какие-то готовые статьи, в которых об этом уже рассказано.

Я уже писал, что тлб-мисы притянуты за уши. Сейчас ты другое пытается притянуть за уши.

Отлов переполнения стека такая себе задача и полезность её сомнительна. У тебя может переполниться в 10других местах. Поэтому на сишке ты вообще писать не должен - если тебе нужны проверки на переполнение.

Поэтому надо определиться. А твои остальные выводы никакого отношения к теме не имеют и не стоят ничего.

Чё?

переключения (обычно их называют системными вызовами) являются основным тормозом любого современного серверного приложения

Системные вызовы умеют не переключать задачи. Более того, память ядра подрублена к каждому процессу и только защищена от чтения из ring3, так что при системном вызове не трогается даже mm.

Сама фраза звучит как «взаимодействие по сети является основным тормозом любого современного сетевого приложения».

Кстати, примерно на эту тему можно почитать срачи о kdbus двухлетней давности.

ЗЫ. Думал, что есть какие-то готовые статьи, в которых об этом уже рассказано.

Нет, готовых я не смог сейчас найти в открытом доступе.

Тогда с pthreads и boost::fiber я и сам смогу налабать при случае. Спасибо за информацию.

не понял

в этом-то и проблема

большие страницы ещё быстрее запачкаются в таких условиях

переходим на личности? ну-ну

в оригинальном комментарии я всё сказал

в этом-то и проблема

большие страницы ещё быстрее запачкаются в таких условиях

все еще не понимаю; ты хочешь сказать, что нельзя будет отсвопить какие-то страницы на диск или discard-нуть их? я считаю, что и не надо — 400М для серверного приложения это нормально

Я тебе советую следить за контекстом

ты можешь дать расширенную цитату со словом «дополнительные»?

именно из-за твоей дизлексии, помноженной на юношеский максимализм, с тобой невозможно разговаривать по делу

переходим на личности? ну-ну

У анонима на LOR-е появилась личность? Да вы никто и звать вас никак, мульон вас здесь таких.

в оригинальном комментарии я всё сказал

Поскольку я не понял, что именно вы хотели сказать, то толку от вашего комментария ноль и вы могли его не писать.

смотри на одну строчку выше, баран

Сама фраза звучит как

не надо перевирать мои высказывания.

Системные вызовы умеют не переключать задачи

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

конечно, 400м — нормально.

когда почти 20 лет назад писали про с10к, эти 10к в потоках весили порядка 20-30мб, при наличных на типичном сервере 64-128. обсуждающие этот топик неадектваты тогда ещё памперсы пачкали, а сегодня вдруг проснулись.

пысы капча pollution calle как бы намекает

прошу модераторов рассмотреть оскорбление участников дискуссии

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

по существу тебе сказать нечего, поскольку ты способен обсуждать только «сохранение регистров», которое к делу отношения не имеет

Обсуждаю то, на что хватает разумения и остаточных знаний. Только вот те, кто делают вид, что знают/понимают больше, либо строят из себя обиженную девочку, либо ограничиваются типа глубокомысленными вопросами «нахрена ты постишь то, в чем не разбираешься», как будто это кому-то какую-то полезную информацию дает.

Да еще из под анонима, коих тут как мух. Заведите себе аккаунт, дабы история глупости на поверхности лежала. А то ничем от кучи неадекватов не отличается, но строит из себя хз кого.

нахрена ты постишь то, в чем не разбираешься

опять искажаешь мои высказывания?

давай немного по делу:

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

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

опять искажаешь мои высказывания?

Искажаю? Да ладно:

но зачем ты постишь цитаты, смысл которых не понимаешь?

Это все, что вы позволили изречь. Очень информативно, да.

статья с10к времён третьего пентиума говорит о том

При чем здесь статья c10k времен третьего пентиума? Моя цитата была взята отсюда: https://www.quora.com/How-does-thread-switching-differ-from-process-switching... Это 2012-й год.

когда почти 20 лет назад писали про с10к, эти 10к в потоках весили порядка 20-30мб

как интересно... и как же 1 нить умудрялась весить 2-3 кб, если размер страницы на х86 это 4кб?

Так мы же всё-таки можем обойтись без гвард-страниц и все стеки так же как и с еполлом аллоцировать в одной гигабайтовой странице.

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

там же есть разные названия, для чего-то более легкого, типа fiber

соглашусь на «треды без гвард-страниц»

Если хотите и нечего делать в пятницу вечером, можем договориться о бенчмарке, чья методология устроит всех присутствующих, я напишу его реализацию на pthreads и boost::fibers, Вы сможете написать на зелёных нитях го, потом замерим разницу в работе.

было бы замечательно, если бы какой-то добрый человек это написал

а я, если мне не лень будет, напишу че-нить для замера влияния tbl miss-ов

pthreads позволяет аллоцировать стек заранее (хоть маллоком) и передать указатель на него и его размер при создании потока. Так что это будет обычный тред, но без гарда. Да и в реальной жизни этот одностраничный гард помогает далеко не всегда...

Так что и с потоками можно использовать большие страницы. Здесь так сказать паритет.

TLB miss rate и соответственно average memory access latency зависят не от количества потоков, а от размера воркинг сета. Вот ни разу не понятно, отчего при использовании потоков воркинг сет радикально больше по сравнению с использованием еполл-реактора. В реакторе то логики в юзерспейсе придётся написать больше, логике структуры данных нужны. Поэтому наоборот, в юзерспейсе воркинг сет у реактора должен быть больше, хотя и не радикально.

Померяй https://pastebin.com/AMD6LQrw.

Там баг в функции echo(). Если ее вызовут по событию POLLIN, а в буфере будут недописанные клиенту данные, а при их записи вернется EAGAIN, это событие POLLIN не будет обработано. А изза POLLET нового события POLLIN не будет. Чтение из сокета прекратится.

Чтение из сокета прекратится.

…до того момента, пока её не вызовут по EPOLLOUT. А до этого читать ничего не имеет смысла — записать-то не сможем.

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

Я рассматриваю в данной дискуссии треды с точки зрения ядра. Ядро стек для тредов не выделяет специальным образом — все guard pages и дополнительные mmap() добавляет glibc.

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

Да и в реальной жизни этот одностраничный гард помогает далеко не всегда...

и в каких случаях одностраничный гвард не помогает?

Так что и с потоками можно использовать большие страницы. Здесь так сказать паритет.

нет, паритета нет: количество страниц может быть равным, но гарантии явно пониженные

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

я не утверждал, что воркинг сет будет больше при равном количестве страниц

В реакторе то логики в юзерспейсе придётся написать больше, логике структуры данных нужны.

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

но все равно, эти копейки считать не стоит — окончательно можно считать «количество страниц равное, гарантии корректности пониженные; равный уровень гарантий ведет к огромному увеличению числа страниц»

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

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

вывод: «количество страниц равное, гарантии пониженные; равный уровень гарантий ведет к огромному увеличению числа страниц»

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

void f() {
    int a = 1;
    char buf[8192];
    int b = 2;
    /* */
}

Функция с таким фреймом вполне себе перескакивает гард и модифицирует память ниже гарда. Потенциально любая функция, в фрейме которой есть неинициализированная локальная переменная размером не менее 4 кб.

Коллбеколапша тоже в целом предоставляет пониженные гарантии корректности работы по сравнению с обычным линейным кодом.

Вообще, добавить такую гарантию ручками не сложно, если очень хочется:

thread_local uintptr_t stack_end;
#define CHECK_STACK() do { register uintptr_t rsp asm ("rsp"); \
                           if (stack_end - rsp < 1024) { \
                             throw std::runtime_error("overflow"); \
                           } \
                         } while (false)

Если хочется автоматики, то можно собрать с -finstrument-functions и добавить

void __cyg_profile_func_enter(void *, void *) { CHECK_STACK(); }

Да, но у GCC есть флаг типа fstack-protector, который умеет проходиться по фрейму таких функций и каждые 8кб записывать байтик.

а эксепшены из __cyg_profile_func_enter разве можно кидать? (я правда не знаю, но судя по слову «профайл» функция для другого придумывалась)

char buf[8192];

Функция с таким фреймом вполне себе перескакивает гард и модифицирует память ниже гарда.

это происходит в том случае, если страницы по 4К, а в случае epoll никто не мешает нам использовать страницы по 2М, и при некоторой возне вообще в 1Г (в то время как 2М-страницы в тредах переполняют тлб)

т.е. твой аргумент, в общем-то, за epoll ;-)

Коллбеколапша тоже в целом предоставляет пониженные гарантии корректности работы по сравнению с обычным линейным кодом.

я ждал, пока это кто-то скажет

по моему *личному* мнению, это самый серьезный аргумент

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

но вроде ведь щас че-то делают на эту тему? типа c# async?

конечно имелось в виду:

(в то время как 2М-страницы в тредах держат кучу байт пустыми)

Отлов переполнения стека такая себе задача и полезность её сомнительна. У тебя может переполниться в 10других местах.

Переход перекрестка на зеленый свет такая себе задача и полезность её сомнительна. Тебя может убить метеоритом в 10других местах.

register uintptr_t rsp asm ("rsp");

первый раз такое вижу... а так разве можно? (я бы в асме вычел stack_end - rsp и вернул значение в переменной)

А можно ссылочку на это изменение?

Окей, я надергаю цитат которые смогу найти неудаленных. Не прям сейчас, 2-30 ночи у меня. Если тред снесут, я создам новый и тебя кастану.

я соглашусь с i-rinat в том, что ты царя переоцениваешь сильно; еще добавлю, что с ним дискуссия похожа на галдеж стаи птиц, а интересное начинается только тогда, когда в тред приходят знающие люди

вот чтобы облегчить тебе задачу надергать, я запастил пару тредов *вместе* с удаленными:

https://pastebin.com/5YyjZpY1 это про 10К

https://pastebin.com/AqRpwjzh это Потоки в Julia: зелёные или нормальные?

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

Чё? Можно какую-то краткую выжимку предыдущих серий?

краткой выжимки не знаю, 2 предыдущие серии 1 постом выше

Твой шанс ещё не истрачен, поэтому я пока что с тобою не буду играть серьёзно.