Линус о выборе планировщика

>сказал Линус Торволдс

O_o. Его теперь так зовут?

О Боже , какая трагедия! Давайте их рассудим и оставим старый планировщик!

>Линус Торволдс

Ересь какая-то. На кол аффтара новости и проверяющего.

Доберусь до работы - буду сравнивать новый планировщик с QNX'овским.

>Ересь какая-то. На кол аффтара новости и проверяющего.

просто грибы, видать, хорошие были :)

в догонку, что думает Линус о судьбе почти_одноименной операционки на десктопе: http://www.realworldtech.com/forums/index.cfm?action=detail&id=81428&...

Well, that's really where Con's issue is. I merged the improved scheduler a few weeks ago, I just didn't merge *his* version.

The reason? There were things like double-blind studies comparing the two, and there really was no difference. And as a top-level maintainer, I need to not just look at things like that, but also at whether I can trust the developer to stick around and fix up the inevitable problems that come from big changes like that.

So when I have a choice between two code bases, both of which perform equally well, but one of which is from the current scheduler maintainer (admittedly egged on by the fact that Con was able to improve noticeably on his older version) who I know is responsible, the thing really is pretty much a no-brainer.

Con was attacking people who reported problems. Ingo (the author of the other patch) was trying to help them track down the cause of the problem.

Who do you think gets his code merged?

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

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

коливасокапец, однозначно

>коливасокапец, однозначно

Он сам капец себе и сделал. Патчсет у него хороший, но нефиг на людей кидаться, а потом бежать и давать плаксивое интервью о том, что его обидели и он ангел.

>>коливасокапец, однозначно

>Он сам капец себе и сделал. Патчсет у него хороший, но нефиг на людей кидаться, а потом бежать и давать плаксивое интервью о том, что его обидели и он ангел.

ваще удивляюсь как при такой модели разработки (когда каждый делает чё ему вдумается) можно получить какой-нибудь рабочий результат.

>ваще удивляюсь как при такой модели разработки (когда каждый делает чё ему вдумается) можно получить какой-нибудь рабочий результат.

Вот для этого есть Линус, который отгружает в ядро только то, что надо.

После прочтения текста и пары тамошних комментариев, у меня сложилось впечатление, что Линус, толком не разобравшись, сильно обидел Кона. Что называется, "срубил с плеча". Кон, будучи уязвленным (еще бы, создатель первого хорошего планировщика), решил громко хлопнуть дверью и покинуть проект. Печально.

> ваще удивляюсь как при такой модели разработки (когда каждый делает чё ему вдумается) можно получить какой-нибудь рабочий результат.

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

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

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

>Вот для этого есть Линус, который отгружает в ядро только то, что надо.

Вот то что линус и только он единолично принимает подобные решения и вызывает беспокойство. Вот случись что с Лиинусом, что будет с ядром? Хаос и анархия (десяток основных маинтейнеров, разругавшись начнут поддерживать каждый свою ветку)! В то время как в freeBSD и оффтопике отход от дел лидера ни на что существтвено не повлияет, потому что сущствует авторитетная группа людей которая всегда согласованно принимает решения, Билл Гейтс вон вообще отошел от дел а его компания сVISTтит ничуть не смутившись.

Вся эта история дурно пахнет.

Линус увидел только один e-mail о том, как Кон резко ответил человеку, которому донимал его и которому не нравилось честное распределение ресурсов процессора. На основании этого он сделал вывод, что Кон де неустойчивая личность и лучше пускай Инго займётся поддержкой планировщика в долгосрочной перспективе.

Ещё Линус упомянул единственный случай OOPS'a после включения SD в -mm ветку, о котором больше никто никогда не упомянул, ибо Кон, видимо, сразу решил проблему.

Линус по-прежнему игнорирует проблемы CFS на некоторых desktop workload'ах с участием 3d графики.

Дряная история, в конце которой мы потеряли полезного человека. Если бы не Кон, никогда мы бы не получили preemption и прочие человеческие радости в 2.6.x.

Одно я не понимаю: почему нельзя было включить и SD, и CFS с возможностью выбора их at compile time? Это было бы справедливо и не усложняло бы run-time ядро.

CK дал о себе знать: http://lkml.org/lkml/2007/7/28/179

Interesting... Trying to avoid reading email but with a flooded inbox it's
quite hard to do.

A lot of useful discussion seems to have generated in response to people's
_interpretation_ of my interview rather than what I actually said. For
example, everyone seems to think I quit because CFS was chosen over SD (hint:
it wasn't). Since it's generating good discussion I'll otherwise leave it as
is.


As a parting gesture; a couple of hints for CFS.

Any difference in behaviour between CFS and SD since they both aim for
fairness would come down to the way they interpret fair. Since CFS accounts
sleep time whereas SD does not, that would be the reason.

As for volanomark regressions, they're always the sched_yield implementation.
SD addressed a similar regression a few months back.

Good luck.

Меня терзают смутные сомнения, что он твой родственник.

>Линус по-прежнему игнорирует проблемы CFS на некоторых desktop workload'ах с участием 3d графики.

Ну так и компостируй мозг Линусу и Инго, воспроизводя эти проблемы и оттачивая своё знание английского не на ЛОРе.

>Дряная история, в конце которой мы потеряли полезного человека. Если бы не Кон, никогда мы бы не получили preemption и прочие человеческие радости в 2.6.x.

Почему-то у меня при упоминании preemption Инго Молнар вспоминается скорее, чем Кон Коливас. Там он тоже гнусно подсидел Кона, пользуясь знакомством с Линусом?

>Одно я не понимаю: почему нельзя было включить и SD, и CFS с возможностью выбора их at compile time? Это было бы справедливо и не усложняло бы run-time ядро.

А нафига два практически одинаковых шедуллера. И так исходники ядра один и самых больших пакетов в дистрибутиве.

Линус принимает откаты?

>И так исходники ядра один и самых больших пакетов в дистрибутиве.

Ну после гнумов/кедов, наверное?

Линус Торвальдс, Дэвид Даймонд. "Just for fun": <...> С технической точки зрения решения не вызывали проблем - труднее было дипломатично сообщить одному человеку, что я предпочел решение другого. Иногда достаточно было просто написать: "Поправки такого-то работают прекрасно. Давайте на них и остановимся". <...> Например, если двое создают однотипные драйверы, я иногда принимаю варианты обоих и смотрю, каким чаше пользуются. Обычно один становится более популярным. Или же авторы начинают совершенствовать свои программы и в итоге их пути расходятся - они начинают использоваться в разных сферах.

:)

гном состоит из кучи мелких пакетов, кеды из чуть более крупных. Из популярных пакетов больше ядра по-моему только JRE и tetex/texlive, если его на отдельные пакеты не делят, как в дебиане.

> А нафига два практически одинаковых шедуллера. И так исходники ядра один и самых больших пакетов в дистрибутиве.

Вы даже не в курсе того, как они работают, а уже делаете далеко идущие выводы:

Ещё раз озвучу Con Kollivas:

Any difference in behaviour between CFS and SD since they both aim for fairness would come down to the way they interpret fair. Since CFS accounts sleep time whereas SD does not, that would be the reason.

As for volanomark regressions, they're always the sched_yield implementation. SD addressed a similar regression a few months back.

Тут дали ссылку на всю дискуссию на LKML, прочтите, пожалуйста.

Этот довод Линуса пожалуй самый несущественный.

Ходить по ссылкам не есть в традициях ЛОРа!

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

именно этот момент и хотелось отметить. решающую роль играют эмоции и личные отношения, а не технические моменты. жаль (

С каких это пор слово 'perfect' стало переводится как "прекрасный"? Когда в русском стали использовать одинарные кавычки?

2 moderators:

s/'прекрасен'/"совершенным"/

s/старый, SD и CFS/старого, SD и CFS/

слово что раз дцать используется :-(

2 furs: перечитай свою новость *медленно* хотя бы раза три, прежде чем добавлять.

> Одно я не понимаю: почему нельзя было включить и SD, и CFS с возможностью выбора их at compile time? Это было бы справедливо и не усложняло бы run-time ядро.

+1

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

Змий питон сломал себе хребет, ползя по генеральной линии партии, определяемой тов. Торвальдсем.

Присоединяюсь к вопросу:"А кто мешал включить несколько планировщиков и просто добавить еще один параметр сборки?"

А тем временем народ медленно, но верно переходит на x86_64. И что мы видим: в ядре 2.6.22.1 продолжает жить один серьёзный баг (в федоре достаточно попробовать команду updatedb чтобы понять о чём речь). В общем сыровато ядро для вживления в него не менее сырых Xen и прочих необкатанных модулей.

Одно из первых правил программиста - ниогда не дублируй одинаковый код

"Одно из первых правил программиста - ниогда не дублируй одинаковый код" При сборке осталось бы одна копия.

причем тут сборка? дублирование кода это признак непрофессионализма, это повторение одинаковых ошибок, и наступание на одни и те же грабли снова и снова

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

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

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

А нафиг держать два комплекта кода, делающего одно и то же с примерно одинаковой эффективностью.

>С каких это пор слово 'perfect' стало переводится как "прекрасный"? Когда в русском стали использовать одинарные кавычки?

>2 moderators:

>s/'прекрасен'/"совершенным"/

Если уж на то пошло, то символ " кавычками не является.

>А нафиг держать два комплекта кода, делающего одно и то же с примерно одинаковой эффективностью.

Линус Торвальдс, Дэвид Даймонд. "Just for fun":

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

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

> дублирование кода очевидно - и сам Линус и Кон говорят что эти два
> планировщика одинаковы как по принципам, так и по эффективности
> работы, следовательно большинство кода выполняющего оиданоковую
> функцию легко можно было бы обьеденить, разве это не дублирование?

спрашивается, напуркуа тогда инго молнар писал свой планировщик, если он делает то же самое, что и кон коливасовский ?

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

>самое прямое - любое измение интерфейсов ядра может подломать работу планировщика или потребовать переделки кода,

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

>и отслеживать это прийдется в двух разных ветках

Зачем 2 ветки?

>а дублирование кода очевидно - и сам Линус и Кон говорят что эти два планировщика одинаковы как по принципам, так и по эффективности работы

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

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

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

> спрашивается, напуркуа тогда инго молнар писал свой планировщик, если он делает то же самое, что и кон коливасовский ?

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

> Какая разница, 2 планировщика при этом будет или один? Каждый разработчик изменит свой модуль

и каждый может допустить какую-нибудь ошибку

> и отслеживать это прийдется в двух разных ветках

имелось в виду в двух подпроектах

> Отлично, но это не говорит о том, что они использую идентичный код

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

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

Важна чистота и прозрачность кода, а не то что одно из двух в результате пойдет в ядро при сборке

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

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

действительно, планировщиков I/O вон сколько в ядро напихали. слоэно было и тут чтоль 2 на выбор сделать?

>приведёт к необходимости разработчиков двух независимых модулей находить компромиссы, касательно изменений, вносимых в общие части

что заставит их обговаривать основные принцивпы работы планировщиков - одна голова хорошо, а две лучше

> Речь идёт о двух независимых проектах, один из которых в конечном итоге надо выбрать

"Или же авторы начинают совершенствовать свои программы и в итоге их пути расходятся - они начинают использоваться в разных сферах." :)

> Почему-то у меня при упоминании preemption Инго Молнар вспоминается
Ну и почему же?
Автором preemption был Robert M Love.

> ваще удивляюсь как при такой модели разработки (когда каждый делает чё ему вдумается) можно получить какой-нибудь рабочий результат.

man evolution
делает что вздумается, а в мейнстрим идет только то, что хорошо получилось.

Да дело не в том, что Коливас якобы на кого-то кидается. Все дело в том что он "не привязан" к разработке ядра, это лишь небольшая часть его жизни, у него другая работа, другая жизнь - это лишь хобби. Следовательно, он мог бы сделать то, что он сделал (бросил разработку), несколько позже, когда бы его планировщик был уже в ветке лишь потому, что ему это занятие просто наскучило. А кто будет поддерживать его код? Почитайте интервью с Коном. Его мотивация имеет исключительно эгоцентричный характер. В этом плане он не надежен, о чем и говорит Линус.

При всем уважени к, вероятно, замечательному человеку и талантливому разработчику Кону Коливасу.

>что заставит их обговаривать основные принцивпы работы планировщиков - одна голова хорошо, а две лучше

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