LINUX.ORG.RU

Ingo Molnar планирует убить Big Kernel Lock

 


0

3

12 лет назад Linux стал поддерживать многопроцессорные системы. Тогда же для предотвращения "логических гонок" (race conditions) без существенного изменения драйверов и других частей ядра был введен Big Kernel Lock, как временная мера до появления более совершенных механизмов синхронизации. Однако с течением времени для уменьшения задержек (latency) реализация Big Kernel Lock усложнялась: например, было добавлено вытеснение (preemption).

Недавно Linus вернул реализацию Big Kernel Lock к старому варианту (spinlock), и тем самым потерялась возможность вытеснения. По его словам, единственным приемлемым способом избавиться от задержек является уничтожение Big Kernel Lock из всех 1300+ мест, в которых он используется. Однако, по оценкам Ingo Molnar, с текущими темпами этот процесс может занять порядка 10 лет. Причина: Big Kernel Lock слишком прозрачен. Теперь слишком легко, даже не подозревая об этом, добавить код, который захватывает BKL, и для большинства строк кода никто наверняка не знает, захвачен он в данной строке или нет. Кроме того, автоматическая проверка вложенности блокировок (lockdep) не знает о Big Kernel Lock, и поэтому слишком просто создать труднообнаружимый deadlock.

Для ускорения процесса удаления Big Kernel Lock Ingo Molnar создал git-дерево, в котором Big Kernel Lock стал более "видимым" (добавлены отладочные средства и поддержка lockdep), и его использование удалено из основного кода ядра.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от Casus

>Так вот, нету в этой цепочке BKL

А кто говорил что она там есть ?

sS ★★★★★
()
Ответ на: комментарий от Die-Hard

>Ну, ИМХО разрывы ядра тут никак не помогут! Задержки, конечно, зло, но если один процесс занят чем-то я ядре, то второму перебивать его нет ни малейшего резона, только дольше будет.

Это смотря чем занят. Типичная задача (у меня) тратит время на передачу данных до 40% (!) . И передача может быть очень неравномерной. Cтруктура кластера вообще говоря неоднородна, обмен может быть с соседним ядром, соседним сокетом (у меня NUMA) или соседним узлом. Оптимизировать эти 40% вполне себе игра стоящая свеч.

sS ★★★★★
()
Ответ на: комментарий от Die-Hard

>мы сейчас флаг CONFIG_PREEMPT_VOLUNTARY обсуждаем...

Кстати подсмотрел в ofa_kernel-1.3 - его нет ;)

sS ★★★★★
()
Ответ на: комментарий от sS

> Оптимизировать эти 40% вполне себе игра стоящая свеч.

Да, но как тут поможет выталкивание процесса, находящегося в ядре?

Если процессор занят ядерным системным процессом, то его все равно не перебить. Если ядерная нить занята полезным процессом, то зачем его вообще перебивать, независимо от состояния, в котором он находится? В числогрызах перебивать вообще некому: каждый процессор поедается одним юзерспейсным процессом, и перебить его (кроме системных ядерных процессов) могут только мелкие системные процессы (типа sshd или powersaved) . И чем меньше они это будут делать, тем лучше для всех...

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

Я надеюсь, что понимаю :-)

Просто хотел, чтобы крики про то, что "Солярка Лиупс порвет на SMP" были разрушены человеком, который понимает разницу между масштабируемости и наличием BKL

annoynimous ★★★★★
()
Ответ на: комментарий от Die-Hard

> Если процессор занят ядерным системным процессом, то его все равно не перебить

Ы? o_O

> Если ядерная нить занята полезным процессом, то зачем его вообще перебивать, независимо от состояния, в котором он находится?

Ыыыы...

> В числогрызах перебивать вообще некому

Числогрызы? Кому нужны эти числогрызы... :D

P.S. у меня такое впечатление, что я читаю тему 10-летней давности. Интересно, чем Линусу не внезапно не понравился вытесняемый BKL.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Кажется господам пора начинать 2.7 (кстати, даже уже поздно- preemеpt то сломали) или наступит смерть пингвину от егонного родителя.

anonymous
()

Странно что такие объемные проекты берется делать сторонний адын человек, а такие $-предприятия как RedHat. Последние поимеют работу этого негра и будут еще удачнее продавать "свою" ОС

anonymous
()
Ответ на: комментарий от anonymous

> Странно что такие объемные проекты берется делать сторонний адын человек, а такие $-предприятия как RedHat

Ingo Molnar и есть RedHat 8)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

2tailgunner:

:-) От тебя не ожидал...

> Интересно, чем Линусу не внезапно не понравился вытесняемый BKL.

По ссылке сходить не пробовал? ;-) Я, кстати, очень коротко написАл немного выше основные положения ссылок Casus'а.

> Числогрызы? Кому нужны эти числогрызы... :D

Да, да! Компьютеры уже давно ничего не считают, теперь это игровая приставка с опциональными функциями пишмашинок, магнитофонов и телевизоров...

:-)

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

> :-) От тебя не ожидал...

А я от тебя :)

>> Интересно, чем Линусу не внезапно не понравился вытесняемый BKL.

>По ссылке сходить не пробовал? ;-)

Нить длинная, всю еще осилил.

>> Числогрызы? Кому нужны эти числогрызы... :D

>Да, да! Компьютеры уже давно ничего не считают, теперь это игровая приставка с опциональными функциями пишмашинок, магнитофонов и телевизоров...

Они еще считают, но уже совсем редко и немного :D А в основном они рулят процессами разной степени реалтаймовости, ага ;)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Они еще считают, но уже совсем редко и немного :D А в основном они рулят процессами разной степени реалтаймовости, ага ;)

Оставляя в стороне имманентно дискуссионный характер данного утверждения, замечаю, что мы-то с sS говорили именно о числогрызах!

:-)

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

> Да, но как тут поможет выталкивание процесса, находящегося в ядре?

Там кроме счётной задачи болтаются всякие мониторы-шмониторы ресурсов типа ganglia и всякая разная другая хрень. И её довольно много.

sS ★★★★★
()
Ответ на: комментарий от tailgunner

>Числогрызы? Кому нужны эти числогрызы... :D

Числогрызы сейчас расходятся как горячие пирожки, отбирая огромные партии последних топовых многоядерных камней у серверного рынка ;)

sS ★★★★★
()
Ответ на: комментарий от sS

> ...всякие мониторы-шмониторы ресурсов типа ganglia и всякая разная другая хрень. И её довольно много.

Она в ядре почти не бывает. Даже если ее вообще выкинуть, тебе это даст доли процента...

Die-Hard ★★★★★
()
Ответ на: комментарий от anonymous

> Странно что такие объемные проекты берется делать сторонний адын человек, а такие $-предприятия как RedHat. Последние поимеют работу этого негра и будут еще удачнее продавать "свою" ОС

Ну откуда беруться такие тупые и ленивые anonymousЫ ????? Читай как мантру: http://en.wikipedia.org/wiki/Ingo_Molnar

fi ★★★
()
Ответ на: комментарий от Die-Hard

>Она в ядре почти не бывает

Если бы. Я был сильно удивлён сколько UDP мусора генерирует эта хрень во внутренней управляющей сети (не в основной среде передачи)

> Даже если ее вообще выкинуть, тебе это даст доли процента...

В сильносвязанной задаче это может вылиться во вполне приличные цифры. Стоит слегка "застрять" одному воркеру и вся задача "встаёт" на небольшой момент времени. А сейчас умножь число таких "остановок" на сотню-другую воркеров.

sS ★★★★★
()
Ответ на: комментарий от sS

> Стоит слегка "застрять" одному воркеру и вся задача "встаёт" на небольшой момент времени.

Воркер, наверное, "застревает" не на ядерном вызове, а где-то в дебрях MPI? От того, что ты будешь рвать ядерные вызовы, воркер только дольше будет там торчать.

Впрочем, что спорить -- надо просто попробовать. Правда, это не так просто сделать...

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

>Воркер, наверное, "застревает" не на ядерном вызове, а где-то в дебрях MPI?

Там часть "дебрей" как раз в ядре.

sS ★★★★★
()
Ответ на: комментарий от sS

Если ваши числогрызы хоть сколь-нибюкь заметное время проводят в ядре, т.е. io-bound, то это не числогрызы, а так...

В вашем случае вы вообще не узнаете, бывает или нет BKL. Собственно, подавляющее большинство операций работают без BLK, о чем подавляющее большинство читателей и не знают.

anonymous
()
Ответ на: комментарий от anonymous

>Если ваши числогрызы хоть сколь-нибюкь заметное время проводят в ядре, т.е. io-bound, то это не числогрызы, а так...

Дело не в числогрызах как таковых а в задачах на них решаемых.
Они бывают _очень_ разными. 

Для примера procinfo с мастера

Linux 2.6.16.27-0.9-smp (geeko@buildhost) (gcc 4.1.0) #1 SMP Tue Feb 13 09:35:18 UTC 2007 4CPU [hyperblade-master.]

Memory:      Total        Used        Free      Shared     Buffers
Mem:      16496184    16144132      352052           0      164396
Swap:      2104472          92     2104380

Bootup: Mon Apr 14 12:24:12 2008    Load average: 4.18 4.34 4.34 5/178 19382

user  :  98d  1:17:03.35  76.0%  page in :  100532491  disk 1:   610597r153625236w
nice  :       1:56:59.89   0.0%  page out: 5687102888
system:       6:52:38.25   0.2%  page act:   61011419
IOwait:   1d 10:56:37.91   1.1%  page dea:    7574833
hw irq:       0:09:51.00   0.0%  page flt:  753303211
sw irq:       3:03:49.68   0.1%  swap in :         35
idle  :  28d 21:40:52.46  22.4%  swap out:         52
uptime:  32d  5:27:26.06         context : 2066126264


То есть 1% в IOWait сходу


sS ★★★★★
()
Ответ на: комментарий от anonymous

>Это на каждом узле?

Только на мастере, на счётных около 0

sS ★★★★★
()
Ответ на: комментарий от sS

Кстати, откуда _столько_ переключений контекста? Это у вас MPI такими маленькими сообщениями все время плюется что-ли? По 2к за запись...

anonymous
()
Ответ на: комментарий от anonymous

>Кстати, откуда _столько_ переключений контекста > Это у вас MPI такими маленькими сообщениями все время плюется что-ли? По 2к за запись..

Почему по 2к ? Там сообщения от нескольких байт до 100-200 Кб

Больший размер смысла не имеет из за резкого падения пропускной способности IB .... совершенно обычный набор сильносвязанных задач (от нескольких сотен до нескольких тысяч пересылок в секунду и до полугигабайта в секунду общего трафика на один воркер)

sS ★★★★★
()
Ответ на: комментарий от sS

Куда-то пропало мое последнее сообщение...

> То есть 1% в IOWait сходу

Это не много! Не вижу, как тут поможет способность прерывать вызовы...

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

О, нашел то, что днем накорябал -- забыл отправить! :-) Так и висит в окошке на работе -- по RDC зашел, увидел. Сейчас кнопочку нажму...

Вообще, с какой стати пересылка больших блоков "сажает" ИБ? Или у тебя не "жирная" (не lock-free) топология?

Die-Hard ★★★★★
()
Ответ на: комментарий от sS

> Там часть "дебрей" как раз в ядре.

Да, но пока оно не не кончит, другие останутся неудовлетворенными!

:-)

Чем дольше ты ему будешь мешать, прерывая ядрёные вызовы, тем больше ему придется пыжиться...

Вызов есть вызов, для логической транзакции (в любом понимании) он ДОЛЖЕН быть закончен. Рвать его оправданно для реалтайма или для чего-либо асинхронного/интерактивного. Ничего подобного в числогрызе нет (И/О не в счет: если возникнет вдруг необходимость в асинхронном И/О, воркер сам это поймет, поймав ексепшен, и отвалится от процессора). Если вдруг бенчмарки показали прирост от ядрёных разрывов, значит ИМХО что-то не так в консерватории...

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

>Вообще, с какой стати пересылка больших блоков "сажает" ИБ? Или у тебя не "жирная" (не lock-free) топология?

У меня вообще не дерево а звезда с одним свитчём. Кластер то "карманный".

Касательно "сажает", просто посмотри совершенно элементарный OSU тест на пересылках точка-точка. У меня даже где то был графичек построен на эту тему, если найду - дам ссылку. Ну и потом я уже писал что у кластера на многопроцессорных, многоядерных узлах _смешанная_ топология. Причём это верно как для ШТЕУД так и для 3-х буквенных камней.

При 6-и сторонней пересылке есть как бы 3 варианта соединения точка-точка. Они будут отличаться как по латентности так и по скорости передачи.

sS ★★★★★
()
Ответ на: комментарий от sS

>Почему по 2к ? Там сообщения от нескольких байт до 100-200 Кб

В серднем на сисколл получается 2к по статистике. Кстати, а что это за сообщения по несколько байт?

anonymous
()
Ответ на: комментарий от Die-Hard

>Это не много! Не вижу, как тут поможет способность прерывать вызовы...

Такого процента вполне хватит чтобы подсадить задачу.

Попробуй между Irecv()/Isend() и wait() вставить явный системный вызов хотя бы в одном ранке а потом посмотри как себя будет вести задача при сотне воркеров.

sS ★★★★★
()
Ответ на: комментарий от anonymous

>Кстати, а что это за сообщения по несколько байт?

Например броадкаст когда рассылаеются глобальные вычисляемые перменные типа переменного шага по времени.

sS ★★★★★
()
Ответ на: комментарий от Die-Hard

>Чем дольше ты ему будешь мешать, прерывая ядрёные вызовы

Имеются ввиду ядерные вызовы не при пересылке сообщений а все остальные. Мастернода как раз занимается активным I/O и сбором всякой статистики. Смысл как раз в том чтобы всё это рвать, давая возможность счётной задаче не тормозить на этих сисколах.

В любом случае мы несколько отдалились от темы ;)

Скорее всего разница у ядер с PREEMPT и без оного будут в пределах статпогрешности, но факт того что зюзеры собрали в общем то серверное ядро с PREEMPT при вскрытии зафиксирован ;)

sS ★★★★★
()
Ответ на: комментарий от sS

> У меня вообще не дерево а звезда с одним свитчём. Кластер то "карманный".

Ну, если свитч один, то он всегда лок-фри. Проблемы начинаются, если одним свитчем не обойтись.

> Касательно "сажает", ...

Я невнимательно на цифры посмотрел -- блок в 200 КБайт вполне. Я в курсе, что начиная с мегабайта у MPI по ИБ проблемы, но, кстати, у MPI по шареной памяти проблемы начинаются еще раньше.

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

Die-Hard ★★★★★
()
Ответ на: комментарий от sS

> но факт того что зюзеры собрали в общем то серверное ядро с PREEMPT при вскрытии зафиксирован ;)

Да, согласен.

Но ИМХО это от недостатка соображения у Новеля :-). К тому же, преемптивность там минимальная, еще до-Лововская.

Die-Hard ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.