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 ()

ждем перевода новости на нормалный русский.

anonymous
()

Скажите несведующему, это та штука из за которой линкс всегда будет сливать соляре на SMP?

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

>мешает часто в области очень мелких таймингов.

Сползай с 2.4.x. Используй >=2.6.24, или 2.6.22 с hrtimer патчами.

Led ★★★☆☆
()

хороший образец рефакторинга:

что то скрытое ->

откроем проблему ->

есть проблема, будем тестить и log вести ->

найдем все места ->

закроем проблему...

denis_ka
()

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

Ingo Molnar взят под арест после пропажи Big Kernel Lock
Соседи Ingo Molnar говорят что видели как он отмывал свое ядро от какого-то кода
Обнаружен компьтер Ingo Molnara со следами Big Kernel Lock
Ingo Molnar объясняет суду зачем выкинул кресло
Ingo Molnar признан в предумышленном убийстве Big Kernel Lock
Alan Cox планирует .... убить ....

не новость, а сюжет для голивуда
интересно, а big kernel lock тоже российского происхождения ?

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

)))))))))))))))))))))))))))))))))))))))))) Да вам, батенька, в петросяны прямая дорога.

anonymous
()

> Недавно Linus вернул реализацию Big Kernel Lock к старому варианту (spinlock), и тем самым потерялась возможность вытеснения.

Зачем?

Preemtion было довольно красивым хаком, зачем было все ломать, может лучше все-таки завести ветку 2.7.x а не корежить 2.6?

anonymous
()

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

Может быть, пора дать этому дереву название 2.7.0 для начала?

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

Догоняйте солярку и бздю, в которой от йетого (GIANT LOCK в их жаргоне) ибавились. ...И можно почитать о dragonflybsd

anonymous
()

Кон Коливас планирует убить Инго Молнара

cascade
()

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

swar0g ★★★★
()

Где же Die-Hard, где же Die-Hard?!

Сейчас он расскажет виндовым троллям, кто лучше всех масштабируется :-)

annoynimous ★★★★★
()

Мухаха... вот это новость, что теперь будут говорить красноглазая братия, Фрюшинкам, раньше ведь говорила, что у нас нет GIANT LOCK-ов, а тут оказуется их полно, предвижу смертельную битву...:-D:-D:-D

ZANSWER
()

Вот сволочи, все ж им неймется. Одни в питоне регулярно GIL пытаются убить, другие в ядре Big Kernel Lock.. Причем и у тех, и у тех при первых попытках все становится медленнее. Хм.

anonymous
()

Сенсация:

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

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

lester, прочтите темы по FreeBSD или OpenBSD, там таких постов полно - это же была почти гордость пионеров, что в GNU/Linux нет Big Kernel Lock-ов, а во FreeBSD или OpenBSD есть GIANT LOCK-и, а тут оказуется их полно ещё, аяяй, не хорошо получилось...:-P

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

> Догоняйте солярку и бздю, в которой от йетого (GIANT LOCK в их жаргоне) ибавились. ...И можно почитать о dragonflybsd

В FreeBSD 7.0 еще не совсем избавились от GIANT LOCK
Процесс идет со времен FreeBSD 5.0

odip ★★
()

External modules have bugs because interfaces change. Film at 11.

                    Linus.

/me пошёл запасаться попкорном ;)

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

> А я думал там всё куда страшнее ;)

Читать оригинальный пост не пробовали? Проблема именно в том, что BKL захватывается неявно, без вызова lock_kernel. И неявно высвобождается на определенных операциях, без видимого unlock'а.

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

>Читать оригинальный пост не пробовали?

Я вообще то всю ветку в LKML прочитал (вчера и сегодня)

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

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

> Проблема именно в том, что BKL захватывается неявно, без вызова lock_kernel.

че за бред - вы сами читать не пробовали?

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

...и объявит все сторонние драйвера что используют BKL бажными (цитату Линуса я приводил ;))

Его надо не просто убрать а заменить на православные мутексы (что в приложенном Инго стартовом патче и делается)

PS: BKL удобная штука когда лень отслеживать сериализацию (сам иногда разводил эту грязь, как временное решение чтобы попробовать будет работать кусок кода али нет, в релизе разумеется это подчищается по мере возможности). Алгоритм чистки довольно хорошо там обсудили. Кстати вытеснение планируется после чистки вернуть.

- makes BKL sections again preemptible

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

>че за бред - вы сами читать не пробовали?

+1

Там речь немного о другом:

The biggest technical complication is that the BKL is unlike any other lock: it "self-releases" when schedule() is called. This makes the BKL spinlock very "sticky", "invisible" and viral: it's very easy to add it to a piece of code (even unknowingly) and you never really know whether it's held or not. PREEMPT_BKL made it even more invisible, because it made its effects even less visible to ordinary users.

sS ★★★★★
()

"Пока гром не грянет, русский мужик не перекрестится." (ц)

Давно пора уже причесывать исходные коды ядра.

Metallic
()

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

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

> Сейчас он расскажет виндовым троллям, кто лучше всех масштабируется :-)

Ты хоть вообще понимаешь, о чем речь идет?

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

Тебя так сильно заботит масштабируемость десктопа? Или ты из тех, кто на серверах юзает рваное ядро?

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

> зачем было все ломать, может лучше все-таки завести ветку 2.7.x а не корежить 2.6?

Гыгы...

Its beginning to sound like should start 2.7 ;)

Alan

http://lkml.org/lkml/2008/5/14/451

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

>> Не понял, вытеснения теперь нет?

> C 2.6.26-rc2.

Да нет же! Только BKL не рвется, а все остальное (по желанию) осталось.

Die-Hard ★★★★★
()

эх ядрышко, куды ты котишься... почти (с)

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

>Или ты из тех, кто на серверах юзает рваное ядро?

ss@hyperblade-master:~> uname -a
Linux hyperblade-master 2.6.16.27-0.9-smp #1 SMP Tue Feb 13 09:35:18 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux
ss@hyperblade-master:~> cat /etc/issue

Welcome to SUSE Linux Enterprise Server 10 (x86_64) - Kernel \r (\l).


ss@hyperblade-master:~> gunzip -c /proc/config.gz | grep PREEMPT
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
# CONFIG_PREEMPT_BKL is not set


Ядро вроде как из коробки (одно из). Как в SuSE собрали так и поставил ;)

Правда мастернода это не совсем сервер ;)


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

RobertWatson активно работает над избавлением GiantLocked (и хака PREEMTION) в коде fBSD и обещано, что FreeBSD-8 предстанет нам без хуге-локов полностью.

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

Надо же, у меня на числогрызах от SGI то же самое!

SUSE Linux Enterprise Server 10 SP1 (x86_64)
SGI ProPack 5SP4 for Linux, Build 504r4-0801072102

# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
# CONFIG_PREEMPT_BKL is not set


Попса! Хотя, CONFIG_PREEMPT_VOLUNTARY=y -- не совсем рваное ядро, а всего лишь расстановка дополнительных точек явного вытеснения. Но в хелпе по этому флагу ясно написано:
Select this if you are building a kernel for a desktop system.

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

>Надо же, у меня на числогрызах от SGI то же самое!

На числогрызах это понятно. Там латентность важна не меньше чем на десктопе. Другое дело что продукт-то _сервер_ (хотя у меня вроде бы что то было про HPC edition в лицензии написано, но я думал что это влияет только на цену лицензии а не на флаги с которыми ядро собрано)

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

> На числогрызах это понятно. Там латентность важна не меньше чем на десктопе.

8-/?

Зачем числогрызу вообще о латентности заботиться?

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

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

Как зачем ? Там же воркеры в отделных процессах и задержки при передаче сообщений между ними весьма сильно влияют на скорость всей задача (по крайней мере у меня обмен сообщениями очень интенсивный как по частоте так и по трафику). Хотя конечно как влияет именно вытеснение это надо потестить ;)

Плюс если на всё это I/O наложить, особенно если он асинхронный.

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

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

Так вот, нету в этой цепочке BKL. Вообще, он в основном в legacy коде.

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

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

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

> Плюс если на всё это I/O наложить, особенно если он асинхронный.

Опять разрыв ядра никак не поможет! Перебиванием ядерного вызова можно лишь _перераспределить_ во времени полезную работу, при этом неизбежно потеряется производительность.

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

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

Ну, нас слегка в сторону унесло :-), мы сейчас флаг CONFIG_PREEMPT_VOLUNTARY обсуждаем...

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