Инго Молнар (Ingo Molnar), известный разработчик Linux ядра и автор планировщика задач CFS (Completely Fair Scheduler), ответил (http://groups.google.com/group/linux.kernel/msg/35ee2ca58bbe...) на заявление Кона Коливаса (Con Kolivas) о выпуске (http://www.opennet.me/opennews/art.shtml?num=23249) нового, простого и быстрого планировщика BFS, серией экспериментов по оценке производительности. Между Коном и Инго установились довольно напряженные отношения, Кон с 2002 года поддерживал разработку O(1) планировщика задач SD (Staircase Deadline CPU scheduler), но его код постоянно откладывался для включения в состав Linux ядра, а в 2007 году Линус Торвальдс отдал предпочтение (http://www.opennet.me/opennews/art.shtml?num=11572) планировщику CFS (http://www.opennet.me/opennews/art.shtml?num=10531), которому в то время было всего несколько месяцев.
В отличие от результатов сравнения (http://ck.kolivas.org/patches/bfs/reverse-scalability.png), представленных автором BFS и подчеркивающих до...URL: http://groups.google.com/group/linux.kernel/msg/35ee2ca58bbe...
Новость: http://www.opennet.me/opennews/art.shtml?num=23313
4096 ядерные компы такие 4096 компы.Кон с самого начала заявлял что делает планировщик с уклоном на уменьшение задержек в _ущерб_ производительности.
ещё бы - в 1\2\4 процессорных\ядерных системах чего больше - мегагерц или процессов ?
Инго очень старался быть вежливым, молодец.
А вот ответ Кона граничит с хамством.
1. вынести выговор с записью в личное дело.
2. премию за планировщик не выплачивать.
за предложенные меры прошу голосовать
>> Инго очень старался быть вежливымНу, дык, Торвальдс это тоже оценил.
> Инго очень старался быть вежливым, молодец.
> А вот ответ Кона граничит с хамством"Автор BFS провел исследование производительности планировщика задач СFS"
И выяснил что положение с CFS закритическое.
И кто после этого граничит с хамством?
CK какой-то грубый стал (или мне показалось).2009/9/7 Ingo Molnar <mi...@elte.hu>:
> hi Con,
Sigh..
Well hello there.
> I've read your BFS announcement/FAQ with great interest:
> http://ck.kolivas.org/patches/bfs/bfs-faq.txt
> I understand that BFS is still early code and that you are not
> targeting BFS for mainline inclusion - but BFS is an interesting
> and bold new approach, cutting a _lot_ of code out of
> kernel/sched*.c, so it raised my curiosity and interest :-)Hard to keep a project under wraps and get an audience at the same
time, it is. I do realise it was inevitable LKML would invade my
personal space no matter how much I didn't want it to, but it would be
rude of me to not respond.> In the announcement and on your webpage you have compared BFS to
> the mainline scheduler in various workloads - showing various
> improvements over it. I have tried and tested BFS and ran a set of
> benchmarks - this mail contains the results and my (quick)
> findings./me sees Ingo run off to find the right combination of hardware and
benchmark to prove his point.[snip lots of bullshit meaningless benchmarks showing how great cfs is
and/or how bad bfs is, along with telling people they should use these
artificial benchmarks to determine how good it is, demonstrating yet
again why benchmarks fail the desktop]I'm not interested in a long protracted discussion about this since
I'm too busy to live linux the way full time developers do, so I'll
keep it short, and perhaps you'll understand my intent better if the
FAQ wasn't clear enough.Do you know what a normal desktop PC looks like? No, a more realistic
question based on what you chose to benchmark to prove your point
would be: Do you know what normal people actually do on them?Feel free to treat the question as rhetorical.
Regards,
-ck/me checks on his distributed computing client's progress, fires up
his next H264 encode, changes music tracks and prepares to have his
arse whooped on quakelive.
>> CK какой-то грубый стал (или мне показалось).Показалось.
Кон предположил несколько пунктов:
1. Инго невнимательно прочитал FAQ (bfs-faq.txt). Или внимательно, но цель написания BFS, указаную в FAQ, проигнорировал.
2. В очередной раз (имеется ввиду шедулеры написанные ранее) Инго подобрал тесты выгодные для утверждения того что CFS круче.Исходя из этого, Кон иронично намекает, что Инго вообще не знает как выглядит десктоп ПК и не представляет чем обычные люди на нем занимаются.
И под конец, разъясняет "для тупых":
- проверяю прогресс в клиенте распределенных вычислений, запускаю следующее H264 кодирование, переключаю музыкальные треки и готовлюсь быть порванным на quakelive.
По-моему, втереть про левые тесты которые не очень то относятся к ДЕСКТОПАМ когда человек сделал шедулер для десктопов - тоже не очень то вежливо? Да, можно сказать что микросоп - хреновый молоток. Но поставить это в минус его создателям - не катит.
Кон Коливас создал BFS не для производительности. А для лучшей интерактивности (грубо говоря: чтобы курсор мыши на экране пользователя не замораживался во время сильной загрузки CPU).Производительность — это другое, не первостепенный аспект на десктопах.
какой толк от этих графиков на десктопе. лучше бы Кон сделал репозитарии для дебиана убунты федоры с собранным ядром с его планировщиком - а юзеры уже сами бы оценили.
Нахрена программеру, ядерному хакеру, заниматься сборкой ядра для твоего Дебиана? Этим другие должны заниматься - сообщество, которое должно было по идее образоваться вокруг патчей Кона Коливаса, но его нет почему-то. Почему - не могу ответить ибо меня это мало волнует. Хочешь - возьмись ты за это дело, заодно сделаешь что-то полезное для своего дистрибутива.
Коливас ответил грубо, но по делу. Тем более, что у Инги радушие лицемерное.Впрочем, лично мне на десктопе CFS нравится даже без спецтюнинга.
холивары на уровне разработчиков... цирк
это называется конкуренция.
а цирк... это лучше у внедренцев-консультантов поспрашать. как не работающие блобы годами внедряют.
BFS слишком сырой пока, и я лично уже это заметил на практике. CFS вполне нормально работает. Если кому-то нужны улучшенные интерактивности -- есть linux-rt.
Открою небольшую тайну - там (на linux-rt) тоже те же планировщики, что и не у -rt и ой как CFQ вешало систему при больших дисковых операциях (iowait непомерно росло) включая ядро 2.6.24-rt - потом выпустили патч - патчил пока не надоело - потом перешел на ядро 2.6.29-rt где патч включили - потом ядро убрали из репов убунту...;)Так что я бы не хвалил CFQ! Он не на много НЕ сырее...
Вы хоть его правильно напишите для начала - CFS
а CFQ - это I/O scheduler - http://en.wikipedia.org/wiki/CFQ
>CFQ, also known as "Completely Fair Queuing", is an I/O scheduler for the Linux kernel which was written by Jens Axboe.са-а-а-фсем другая шняга.
зы:
рантаймовское ведро с медубунтой - полет нормальный
$ aptitude show linux-image-2.6.28-3-rt
Пакет: linux-image-2.6.28-3-rt
Состояние: установлен
......
Описание: Linux kernel image for version 2.6.28 on Ingo Molnar's full real time preemption patch (2.6.28-rt)
>[оверквотинг удален]
>
>са-а-а-фсем другая шняга.
>зы:
>рантаймовское ведро с медубунтой - полет нормальный
>$ aptitude show linux-image-2.6.28-3-rt
>Пакет: linux-image-2.6.28-3-rt
>Состояние: установлен
>......
>Описание: Linux kernel image for version 2.6.28 on Ingo Molnar's full real
>time preemption patch (2.6.28-rt)ой - вот блин - "промахнулся" :))) не туда и не о том... каждый пишет о том - что болит ;)))) LOL
ио-шедулер - вещь интересная.
не скажу, что мне реализация сильно нравиться, но..... к релизам серверных дистров исправиться.
>Так что я бы не хвалил CFQ! Он не на много НЕ сырее...Перепутать планировщики CFQ и CFS - это эпично :)
я лично поставил BFS на gentoo-sources-2.6.30-r6, kde стартанул и все повисло, но я возможно не правильно, что сделал, так как при патчение он ругнулся на два места, сказал, что патч уже есть.Лично считаю, что Инго сравнивал не то, Кон же написал для десктопа.
А хамить не хорошо.
>А хамить не хорошо.не хорошо. но к шедулерам это отношения не имеет.
Линус тоже за словом в карман не лезет.
едиственный критерий качество кода, идеи, необходимости.... ну как-то так.
Поставил BSF на ядро 2.6.30.2 в ubuntu 9.10 beta 5. Всё работает идеально, по ощущениям минимум НЕ медленнее CFS. Моё мнение, для малоядерных процов (до 8) на десктопах стоит делать выбор в пользу BSF.
Да, есть вопрос. Вот CFS специально пытается грузить сначала одно ядро по полной и подключать второе только когда необходимо, и при этом в реальном времени процессы бросает каждый раз на новое ядро т.е. получается что ядро 0 загружено, а ядро 1 пустует через секунду или около того ядро 0 пустует а ядро 1 загружено теми же самыми процессами.
BSF грузит оба мои ядра равномерно, без перетасовки.В чём смысл этих пертурбаций от CFS?
на intel atom а также на power pc если загрузить только одно ядро получается немного быстрее чем раскидывать эту же задачу по двум ядрам. А еще на всех процессорах с необщим кешем ядер например на Athlon, лучше грузить только одно ядро, пока возможно.
Вообще то это не совсем так. Теория говорит всего лишь что не стоит перебрасывать часто один процесс с процессора на процессор если задачи 2 то лучше запускать их на разных процессорах что бы одна задача заполнила кеш одного процессора и работала оптимально а другая другого. но хотя с развитием многоядерности и кешев третьего уровня это преймущество немного скрадывается, но все еще остается.
Т.е. CFS для intel Atom, Athlon и прочих процов с малым кэшем заведомо будет более тормозным т.к. CFS постоянно с ядра на ядро перебрасывает. BSF же такого НЕ делает.
>CFS постоянно с ядра на ядро перебрасывает.Вы сами себе противоречите - то он у Вас только один проц по максимуму грузит, то перебрасывет.
определитесь уж.
>Вы сами себе противоречите - то он у Вас только один проц по максимуму грузит, то перебрасывет. определитесь уж.Млять, специально для тех кто в танке ещё раз.
CFS пытается исполнять на одном ядре, но через определённый квант времени где-то 0.5-1 сек перебрасывает всё на другое ядро физическое ядро. У CFS нет равномерной одномоментной загрузки обоих ядер, у CFS в определённый момент обычно занято обычно одно ядро (только в случае необходимости подключается второе ядро), но это первое занятое ядро через квант времени меняется на другое. Запусти в гноме системный монитор и график загрузки проца посмотри.
специально для тех, кто в окопе:
1. видимо именно поэтому этот планировщик и обгоняет.
2. пруфлик из окопа тяжко достать, но всё-таки попробуй.
3. ему, сцуко, занятся больше не чем, вот он и бросает их туда и обратно.зы:
>у CFS в определённый момент обычно занято обычно одно ядро (только в случае необходимости подключается второе ядро)сцуко, htop мне постонянно врёт видимо. atop и пр. - тоже.
С какого хера мой пост потёрли, аргументов не осталось кроме цензуры?Вот скриншот, ещё будешь утверждать, что CFS с ядра на ядро не гоняет?
http://pobeg1980.livejournal.com/1941.html
гы-ы-ы-ы:
первое.
>BSF отчётливо грузит равномерно оба ядра, CFS рисует кривую как при сердечном приступе. В обоих случаях одна и та же нагрузка - firefox с плагином mplayer показывает из инета ТВ, totem показывает локальный фильм и htop для контроля. Показания htop и гномовского системного монитора совпадают.что доказывает только одно - на каждом проце при CFS работает СВОЙ поток, со СВОЕЙ нагрузкой.
и если потребление ресурса (тут ЦПУ) не равно 100%, то выравнивания (переброса потоков на другие ЦПУ) не происходит.второе:
и вот это - http://pobeg1980.livejournal.com/1941.html - пруфлинк???????зы:
я конечно определённо не девочка.... зачем озвучивать очевидное. плохо с воспитанием?
>что доказывает только одно - на каждом проце при CFS работает СВОЙ поток, со СВОЕЙ нагрузкой. и если потребление ресурса (тут ЦПУ) не равно 100%, то выравнивания (переброса потоков на другие ЦПУ) не происходитГлаза протри и посмотри ещё раз на график. Где там НЕ ПРОИСХОДИТ перебрасывания??? Там совершенно очевидно, что с одного ядра в случае CFS одна и та же нагрузка перебрасывается на другое ядро и обратно.
по графикам видно только одно:
на первом - планировщик даёт потокам поработать (погрузить) свой, перманенто-постоянный проц.
на втором - схожесть графиков говорит, что происходит выравнивание нагрузки по процам. а что это значит? (или вообще бред показывает - не могут процы быть равномерно нагружены если нагрузка не стремится к 0% или 100%)
в довесок: вот в этом комменте - http://www.opennet.me/openforum/vsluhforumID3/58585.html#44 есть пруфлинк.
если его всё-таки прочитать (можно ещё и глянуть там же исходники), то количество бреда в Ваших коментах (думаю... а может и нет. х/з) уменьшиться.
>в довесок: вот в этом комменте - http://www.opennet.me/openforum/vsluhforumID3/58585.html#44 есть пруфлинк.Это только слова, графики на десктопе этого не подтверждают.
>если его всё-таки прочитать (можно ещё и глянуть там же исходники), то
>количество бреда в Ваших коментах (думаю... а может и нет. х/з)
>уменьшиться.Вчера смотрел исходники BSF, Коливас между прочим один из разработчиков CFS судя по комментам, а именно в вопросе интерактивности вносил изменения. Давай показывай пальцем где в исходниках где CFS должен обделывать BSF на дестопе при количестве ядер меньше 8 скажем?
графики там (Ваши) вообще ничего не подтверждают. общая нагрузка на проц и есть - общая нагрузка на проц.
более того, если графики нагрузки на все процы одинаковые (или стремятся к "одинаковости"), то это как раз и доказывает, что потоки перебрасываются и выравнивают нагрузку на обоих (или сколько бы их не было). не говоря уже о дискретности взятия проб для этих графиков. методов сбора (где гарантия, что новый планировщик BSF не искажает данные? ведь судя по графику программы должны работать вдвое быстрее, т.е. визуально должно быть заметно, а этого нет)короче, либо пруфлинк (желательно с анализом кода), либо - в сад (возможно детский).
>ведь судя
>по графику программы должны работать вдвое быстрее, т.е. визуально должно быть
>заметно, а этого нет)
>Для сложения сигналов в шкале 100% - амплитуды сигналов складываются и делятся на количество сигналов...
это в теоретической математике :-Dа на практике следующие постулаты:
1. единицей выполнения является поток
2. поток может выполнятся в определённый момент только на одном проце
3. когда поток выполняется - нагрузка на проц 100%
4. если пишут, что нагрузка 35% - это значит, что 35% от времени наблюдения проц работал, а 65% - нет.
>это в теоретической математике :-D
>
>а на практике следующие постулаты:
>1. единицей выполнения является поток
>2. поток может выполнятся в определённый момент только на одном проце
>3. когда поток выполняется - нагрузка на проц 100%
>4. если пишут, что нагрузка 35% - это значит, что 35% от
>времени наблюдения проц работал, а 65% - нет.Не вижу никаких противоречий в этом...
кроме одного - нет никакой амплитуды сигналов (цифровая техника, мля. не аналоговая).
проц (вернее ядро) в данный момент либо работает, либо нет.
>кроме одного - нет никакой амплитуды сигналов (цифровая техника, мля. не аналоговая).
>
>проц (вернее ядро) в данный момент либо работает, либо нет.Значит вы не имеете ни малейшего понятия об этом: http://ru.wikipedia.org/wiki/Категория:Численные_методы
Вы специально переводите разговор на другую тему?
(я в курсе численных методов. давайте поговорим всёже о планировщиках)
>Вы специально переводите разговор на другую тему?
>(я в курсе численных методов. давайте поговорим всёже о планировщиках)Увы - нет - не перевожу.
Эти методы распространяются на обработку практически любых видов и форм сигналов, в том числе и цифровых, к которым и относится циклограмма работы всех без исключения цифровых интегральных схем, к которым CPU к стати тоже относится...
Это я к тому, что графики УЖЕ отображают огибающую-результат методов расчета загрузки CPU - вот именно по этому я и не видел никакой разницы и тем более противоречий...
>Это я к тому, что графики УЖЕ отображают огибающую-результат методов расчета загрузки CPUа я о чём говорил?
вопрос в другом - каким образом по данным графикам оппонент пытался доказать, что CFS перекидывает потоки с одного цпу (естесствено, предполагается из разговора - без системно и без причинно), на другой.
а вот усреднённая нагрузка со второго графика как раз может говорить и об этом (но не факт).
>>Это я к тому, что графики УЖЕ отображают огибающую-результат методов расчета загрузки CPU
>
>а я о чём говорил?
>
>вопрос в другом - каким образом по данным графикам оппонент пытался доказать,
>что CFS перекидывает потоки с одного цпу (естесствено, предполагается из разговора
>- без системно и без причинно), на другой.
>
>а вот усреднённая нагрузка со второго графика как раз может говорить и
>об этом (но не факт).http://pobeg1980.livejournal.com/1941.html
Поскольку метод отображения/расчетов графиков был один и тот же для разных планировщиков - то данные графики можно считать объективными, и с очевидностью можно сделать вывод о том, что: на верхнем графике (рассматривая степень загрузки ядра как исследуемый процесс) процесс на протяжении 60 сек мигрировал с одного ядра на другое, поскольку уровень одной линии на графике уменьшалься ровно на столько - на сколько увеличивалься уровень другой линии; что нельзя сказать о нижнем графике - с точки зрения методов численного анализа - там (на нижнем...) процессы проистекают практически одинаково - с учетом погрешности метода...
а где гарантия, что планировщик не влияет на сбор данных о загруженности?
>на верхнем графике (рассматривая степень загрузки ядра как исследуемый процесс) процесс на протяжении 60 сек мигрировал с одного ядра на другое,я в данное время не смотрю фильмы... и всё-же количество процессов (не потоков!!!)
$ ps -ef|wc
201 1901 17825
потоков же:
$ ps axms|wc
493 5339 59453
о каком из этих процессов Вы говорите? какой из них мигрировал?
а CPU всего 2... а переключаться между задачами надо.... а CPU всего 2... а переключаться между задачами надо.... а CPU всего 2... а переключаться между задачами надо....
через сколько времени не будет играть роли на каком проце восстановит работу поток будут? (Вы ведь владеете методами? :-D)
>поскольку уровень одной линии на графике уменьшалься ровно на столько - на сколько увеличивалься уровень другой линии;да будет Вам известно, что mplayer (да и флэшь) запускаются в несколько потоков.
обычно в столько, сколько есть в системе ядер (если явно не указать.
>что нельзя сказать о нижнем графике - с точки зрения методов численного анализа - там (на нижнем...) процессы проистекают практически одинаково - с учетом погрешности метода...что говорит, что контекст выполнения переключается ГОРАЗДО чаще между физическими ядрами.
т.е. абсолютно противоположенное, чем то, о чём говорил Дохтор.короче, все эти рассуждения для человека, мало знакомого с деталями....
Я не о том процессе :)))
http://ru.wikipedia.org/wiki/Процесс
http://ru.wikipedia.org/wiki/Случайный_процесс
вот не надо за идиота считать. :-D
не при помощи этого была попытка доказать, что якобы согласно графикам CFS перебрасывает нагрузку с проца на проц.
>вот не надо за идиота считать. :-DИ в мыслях не было...
>не при помощи этого была попытка доказать, что якобы согласно графикам CFS
>перебрасывает нагрузку с проца на проц.С моей стороны я как раз только при помощи этого и пытался доказать - так как в ядерных тонкостях не спец...
ну так поймите следующее:
1. квант премени выполнения конкретной задачи на проце - очень маленькая велична (загрузка проца при этом - 100%).
погрешность измерений (в приведённых графиках) с ним и рядом не стояла.
2. график показывает (усреднённо) работу всех потоков в системе.
3. показатель планировщика - работа в граничных условияхps:
о численных медотах - Вы общались с преподавателем информатики (архитектура, асм, с/с++).
бывшим правда. Ж-ВВВВВВВВВВВВВВВВВв
мне просто интересно общаться с умными (не лесть!!! просто как ещё выразиться)... даже если мнения не совпадают.
просто в данном случае Вы не знаете "чистоты" эксперемента - в частности, как Вы отнесётесь к тому, если загрузка ЦПУ будет всегда 100% и при этом количество процессов будет больше (и они будут отзывчевее), чем в системе, где загрузка 30%.
а ведь такое было уже.
(если вспомнишь сей факт - возьми с полки пирожёк :-D)
>И о численных методах у меня был диплом, который успешно защитил!отличная тема.
вот только там НИКОГДА не ставят под сомнения истинность полученных данных.
>Знали бы вы чуток физику - то поняли бы о чем я тут пытался вам рассказать!физ-мат. отделения физика-информатика.
это математикам не фажны способы получения данных и чистота эксперимента.
>Честь имею!удачи! :-D
>1. квант премени выполнения конкретной задачи на проце - очень маленькая велична (загрузка проца при этом - 100%).Хренасе _очень маленькая_, от 1 миллисекунды до 4-х и выше (если не принимать во внимание dinamics trics). В твоей системе по твоим словам более 5000 потоков, которые за 5 секунд могут только получить шанс выполнится и то не факт.
>2. график показывает (усреднённо) работу всех потоков в системе.
>3. показатель планировщика - работа в граничных условияхБла-бла-бла... демагогия.
1 или 4 к 250 - какой процент?
и покажите на Вашем графике хотя бы 4.
а так же количество процессов (в каждой конкретной точке).
не стоит так самокритично..... всё-таки ты о чём то думал, когда сей бред писал.
не расстраивайся! :-Dна заметку:
что именно выполняет ядро?
и при каких условиях оно прекращает выполнение текущей задачи и переходит к следующей?зы:
задача повышенной сложности:
не забываем про кэш (и кода, и данных).
>я в данное время не смотрю фильмы... и всё-же количество процессов (не потоков!!!)
>$ ps -ef|wc
> 201 1901 17825
>потоков же:
>$ ps axms|wc
> 493 5339 59453Млять, перечитай ещё раз свою книгу грамотей, функция балансировки нагрузки load_balance() у CFS вызывается раз в 200 миллисекунд, ищет очереди в которых потоков на 25% больше чем в текущей и раскидывает по других очередям привязанным к другим ядрам. Именно это и отражено на графике и мои слова про полную миграцию с ядра на ядро раз в 0.5-1 секунду именно это и обозначают. Ядро не может моментально все потоки раскидать, это идёт постепенно.
во всех перечисленных тобой (и мной) книгах на сколько мне известно нет описания CFS (который, насколько мне известно с 2.6.23)
>Млять, перечитай ещё раз свою книгу грамотей, функция балансировки нагрузки load_balance() у CFS вызывается раз в 200 миллисекунд,что говорит о том, что выполняющийся поток перманентно привязан к процу.
какова погрешность по оси X в твоих графиках? ну, грамотей, ответь?
выходит, что именно в BFS перекидывается нагрузка с проца на проц НАМНОГО чаще.
>во всех перечисленных тобой (и мной) книгах на сколько мне известно нет описания CFS (который, насколько мне известно с 2.6.23)В твоей книжонке может и нету, а в книге Linux kernel architecture (Wolfgang Mauerer) есть
страница 107, глава 2.6.2 "CFS Operations". Так же это есть и в книге Роберта Лава на странице 83, глава "балансировка нагрузки">что говорит о том, что выполняющийся поток перманентно привязан к процу.
Ты уже КНИГИ известных людей оспариваешь.
Новые данные, сейчас код CFS поковырял, в коде ядра 2.6.30 балансировка происходит раз в 250 миллисекунд при этом ограниченно число потоков (не больше 32) которые подвергаются балансировке т.к. это происходит при отлючённых прерываниях.
>Новые данные, сейчас код CFS поковырял, в коде ядра 2.6.30 балансировка происходит
>раз в 250 миллисекунд при этом ограниченно число потоков (не больше
>32) которые подвергаются балансировке т.к. это происходит при отлючённых прерываниях.а давайте всё-же конструктивно, я понимаю что никто не решилси серьёзно потестить, но может.....
http://sourceware.org/systemtap/examples/process/chng_cpu.stpможет этот вариант всем подойдёт?
>[оверквотинг удален]
>>раз в 250 миллисекунд при этом ограниченно число потоков (не больше
>>32) которые подвергаются балансировке т.к. это происходит при отлючённых прерываниях.
>
>а давайте всё-же конструктивно, я понимаю что никто не решилси серьёзно потестить,
>но может.....
>
>
>http://sourceware.org/systemtap/examples/process/chng_cpu.stp
>
>может этот вариант всем подойдёт?ну и заодно методика
голый init + 2 агрессивных процесса * число ядер?
не плохо.
действительно, использовать systemtap - это к месту.но боюсь использовать загрузку цп как единственный критерий - не корректно.
BFS (как говорят) создана для увеличения отзыва системы (чтобы это не значило).
а, согласно графикам топика, по производительности на загрузке в 100% она уже слила.зы:
может и займусь (если интересно) написанием рядом скриптов для системтэп.
но только в виртуалке (начальные условия одинаковые).
вот только смысл?
>[оверквотинг удален]
>но боюсь использовать загрузку цп как единственный критерий - не корректно.
>BFS (как говорят) создана для увеличения отзыва системы (чтобы это не значило).
>
>а, согласно графикам топика, по производительности на загрузке в 100% она уже
>слила.
>
>зы:
>может и займусь (если интересно) написанием рядом скриптов для системтэп.
>но только в виртуалке (начальные условия одинаковые).
>вот только смысл?смысла по большому счёту никакого нет.
1. Коливас он конечно молодез определённо, но его хаки многим судя по всему не подуше.
2. и самое главное естественно что CFS не перекидывает каждый раз процесс на другой проц -- это явная глапость.
3. а использовать debug / systemtap нужно было раньше - тогда бы не пришлось "спорить о разном" и высказывать недовольство друг-другом.
P.S. "А вот и не подерётесь , а я не посмотрю" (C) Народная Мудрось
>1. Коливас он конечно молодез определённо, но его хаки многим судя по всему не подуше.я рад что такие люди есть!
он - творец. он что сделал..... я уважаю таких людей.
>3. а использовать debug / systemtap нужно было раньше - тогда бы не пришлось "спорить о разном" и высказывать недовольство друг-другома как?
опять скажут, что тесты не для десктопа.....
>2. и самое главное естественно что CFS не перекидывает каждый раз процесс
>на другой проц -- это явная глапость.Глупость и эту глупость сказал ты.
Мной было сказано, что CFS производит балансировку раз в 250 миллисекунд и перемещает потоки с ядра на ядро при условии, что есть очередь в которой на 25% и более потоков, причём приоритет отдаётся спящим потокам при перемещении т.к. вероятность hot cache тут наименьшая и при отсутствии таковых перемещает работающие потоки.
Смотри kernel/sched.c
>>2. и самое главное естественно что CFS не перекидывает каждый раз процесс
>>на другой проц -- это явная глапость.
>
>Глупость и эту глупость сказал ты.
>Мной было сказано, что CFS производит балансировку раз в 250 миллисекунд и
>перемещает потоки с ядра на ядро при условии, что есть очередь
>в которой на 25% и более потоков, причём приоритет отдаётся спящим
>потокам при перемещении т.к. вероятность hot cache тут наименьшая и при
>отсутствии таковых перемещает работающие потоки.
>Смотри kernel/sched.cmistype а вас зацепило.... больше не к чему было ?
а теперь смотрим пост #(58) и делаем выводы.
и да -- сказал я "глапость" по ошибке - так ведь мне не сложно в этом признаться. 29 лет? точно?
>и да -- сказал я "глапость" по ошибке - так ведь мне
>не сложно в этом признаться.А ты дебил будешь отрицать, что у CFS есть балансировщик нагрузки который гоняет раз в 250 миллисекунд потоки?
>>и да -- сказал я "глапость" по ошибке - так ведь мне
>>не сложно в этом признаться.
>
>А ты дебил будешь отрицать, что у CFS есть балансировщик нагрузки который
>гоняет раз в 250 миллисекунд потоки?аааа.... раз пошла такая, то я себе тоже разок позволю...
а ты животное отчего решил, что если твой проф уровень позволяет тебе мести помойным ебальником на всех вокруг, при этом нести откровенную ахинею то тебя блядина кто-то должен уважать или выслушивать несостоятельные сказки. - иди дрочни на kernel/sched.c и ложись уже спать - завтра модераторы тут всё почистят, включая твой пост #58 - из-за которого мы наблюдаем это падение нравов, "профессионал" блин -- схавал бы давно и никто бы не заметил.
...ух...
прошу прощение уважаемой публики.
блин.
ну а как ещё общаться то?
кто скажет про тот же kernel/sched.c (вон из тебя скоко тянуть пришлось... пока не обозвали)сообщество, мля...
окуеть!!!
а ты, умный чел, будешь отрицать, что в BFS есть планировщик?
тобой тут (http://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi?az=sh...) было сказано:
>CFS постоянно с ядра на ядро перебрасывает. BSF же такого НЕ делает.а вот это:
>Мной было сказано, что CFS производит балансировку раз в 250 миллисекунд и перемещает потоки с ядра на ядро при условии, что есть очередь в которой на 25% и более потоков, причём приоритет отдаётся спящим потокам при перемещении т.к. вероятность hot cache тут наименьшая и при отсутствии таковых перемещает работающие потоки.оговорка по Фрэйду. :-D
самое время прокричать CFS сакс, BFS -форевер.... и вспомнить твой график, как доказательство!!! :-DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
ну кто мог догадаться, что ты имел в иду ровно противоположенное? :-D
(если и так... мог бы поправиться сразу.... не так уж много людей, задумывающихся об этом... могли бы и сотрудничать...)
>... который с ядра на ядро перебрасывает?все перебрасывают.
вопрос в деталях
(для меня критерий уже есть - проц не может жрать 100 пока другой пустует - остальное туфта)
>ну кто мог догадаться, что ты имел в иду ровно противоположенное? :-DЧто противоположное т.е. балансировщик перестал постоянно гонять с ядра на ядро с квантом времени или перемещает только раз и всё?!
>(если и так... мог бы поправиться сразу.... не так уж много людей,
>задумывающихся об этом... могли бы и сотрудничать...)Мне сотрудничать ничего не мешает и сейчас, в этом вопросе политически гибок. предлагайте.
>Мне сотрудничать ничего не мешает и сейчас, в этом вопросе политически гибок. предлагайте.ну ежели так.... имеем в CFS/BFS - разница в различной нагрузке на процы (о периодичности -и графиках пока не вспоминаем) - это как раз и есть показатель, что планировщик до последнего (пока есть хоть малейшая возможность съэкономить на повторном выполнении) держит проц за одним потоком (не процессом), но...
если этот поток из процесса "переднего плана" (Вы там фильмы смотрели вроде?):
- рано или поздно, но этот проц оказывается "более" загруженным, чем второй.
- картина повторяется со вторым процом
- (в кавычках - все mplayer'ы идут в несколько потоков и равны количеству процов.... но это всё равно происходит....)хм... о сотрудничестве.... например могли бы на этом примере разработать набор тестов (и для десктопов в том числе! системтэп - отличное предлежение!) - разработчики шедулеров бы на них ориентировались..... все в плюсе.
опеннет захостил бы такие скрипты?...
Тестирование мне не интересно.
>Тестирование мне не интересно.Мне разработка интересна, за деньги
тебе интересны просто деньги.зы:
лично мне и лично ты - не нужен.
вопрос к модераторам - набор таких скриптов нужен?
>тебе интересны просто деньги.
>
>зы:
>лично мне и лично ты - не нужен.
>вопрос к модераторам - набор таких скриптов нужен?я много плюсую за набор тестов.
может подумаем вместе?
интересно жеж.
я б и сам... токо мне и так всё ясно.
а послушаешь некоторых - думаешь, да пошли вы все.а так - было бы интересно.
этож почти регресс-тест.... очень увеличило б скорость отладки.
>я б и сам... токо мне и так всё ясно.
>а послушаешь некоторых - думаешь, да пошли вы все.
>
>а так - было бы интересно.
>этож почти регресс-тест.... очень увеличило б скорость отладки.скрипты погонять на тачке? - да отчего-же нет? всегда за.
на регресс-тест похоже мало, но хоть посмотрю как там этот bfs робит.
завтра ядра подготовлю, только интересно чем интерактивность мерять, voip под нагрузкой? мыша+x window? - так что эти самые тесты ещё очень долго придумывать - речь то ведь о десктопе идёт, смотрим кино под нагрузкой lzma?мысли?
ок.
я тоже (но в витруалке - vkm + vmx)ps:
>на регресс-тест похоже мало, но хоть посмотрю как там этот bfs робит.по началу - да.
а так - новые ядра вполне можно тестить. (а из-за чего - отдельная песТНя)
>тмысли?олько интересно чем интерактивность мерять, voip под нагрузкой? мыша+x window?
вот и мне интересно - критериев то нет.
на ум приходит только rt.
>мысли?ну... скрипты и есть скрипты... будем пополнять/изменять_пополнять и т.д.
на любой вкус.
вышло ядро (или рк) - протестили... кто-то сказал, что не так... спросим, а как - вот новый скрипт.
ну.. как-то так я думаю (опеннет - новый фороникс!!! :-D)
s/vkm/kvm
>это в теоретической математике :-D
>
>а на практике следующие постулаты:
>1. единицей выполнения является поток
>2. поток может выполнятся в определённый момент только на одном проце
>3. когда поток выполняется - нагрузка на проц 100%при текущей частоте, ядро может понижать частоту проца.
>4. если пишут, что нагрузка 35% - это значит, что 35% от
>времени наблюдения проц работал, а 65% - нет.
>при текущей частоте, ядро может понижать частоту проца.тафтология.
правильно так - при определённой НАГРУЗКЕ (методы подсчёта могут быть разными) ядро (или так - через системные вызовы ядра) может понижать частоту проца.
>графики там (Ваши) вообще ничего не подтверждают. общая нагрузка на проц и
>есть - общая нагрузка на проц.Получается с твоих слов, постоянно гонять ядра на ядро это никак в плане производительности не сказывается, кэш здесь не участвует и не тормозит код из-за отсутствия значений в кэше... Ну-ну.
>более того, если графики нагрузки на все процы одинаковые (или стремятся к
>"одинаковости"), то это как раз и доказывает, что потоки перебрасываются и
>выравнивают нагрузку на обоих (или сколько бы их не было). не
>говоря уже о дискретности взятия проб для этих графиков. методов сбораЭто говорит, что потоки у BFS на пихаются на одно ядро, чтобы второе было свободно для потоков kernel space. Это говорит о том, что BFS исполняет потоки на обоих ядрах одновременно, что НЕ ЗНАЧИТ что он их перебрасывает с ядра на ядро.
CFS же пытается исполнят потоки user space на одном ядре оставляя второе ядро для kernel space и периодически перемещает потоки с ядра на ядро видимо для избежания перегрева одного ядра, возможно ещё из-за каких-то причин. CFS это больше планировщик для много процессорных маших и серверов.>(где гарантия, что новый планировщик BSF не искажает данные? ведь судя
>по графику программы должны работать вдвое быстрее, т.е. визуально должно быть
>заметно, а этого нет)Это вообще трындец, ещё раз глаза протри, где там в два раза превосходство на графике?! Там на несколько десятков процентов превосходство. Что кстати немного заметно.
>короче, либо пруфлинк (желательно с анализом кода), либо - в сад (возможно
>детский).Короче сливаешь, графики я привёл. Ты вякнул про код, так вот анализ кода должен быть с твоей стороны потому, как размер кода CFS раз в 5-10 больше размера кода BFS. Пытаться найти в коде BFS то чего нет это глупо. Давай анализ кода CFS на предмет того почему он должен быть быстрее BFS.
>Получается с твоих слов, постоянно гонять ядра на ядро это никак в плане производительности не сказывается,не понял, что хотел сказать. кто куда и кого гоняет - не понятно...
я не ясно написал, что из твоих графиков это не следует? и пруфлинка, подтверждающего это, от тебя не видел.
> кэш здесь не участвует и не тормозит код из-за отсутствия значений в кэше... Ну-ну.почему? кэш тормозит.
но как это происходит?
для этого и есть планировщики и такие понятия, как контекст процесса, аппаратный контекст, сегмент состояния задачи и т.д.
а вообще, переключение происходит только в одном месте ядра - функция shedule() - рекомендую.
>Это вообще трындец, ещё раз глаза протри...плохо мы ещё воспитываем нашу молодёж...
>Короче сливаешь, графики я привёл. Ты вякнул про код, так вот анализ кода должен быть с твоей стороны ...ну-ну. я (в отличие от тебя) анализ (или объяснение) твоих графиков привёл. а ты даже их не объяснил. (это - "график прыгает, как кардиограмма, азначит потоки перекидываются" - бред сивой кобылы)
короче. слил ты всё, господин студент из меда.
Дядя, про устройство ядра я прочёл три книги две на русском Лав, Бовет и Чезати, и книгу Wolfgang Mauerer на английском почти прочёл потому не нужно мне объяснять где, что переключается.Если для тебя не очевидно, что в случае CFS на графике одна и та же нагрузка перемещается с ядра на ядро считаю диспут с тобой законченным, ты не хочешь видеть очевидного. Имеющий глаза увидит.
>Дядя, про устройство ядра я прочёл три книги две на русском Лав,
>Бовет и Чезати, и книгу Wolfgang Mauerer на английском почти прочёл
>потому не нужно мне объяснять где, что переключается.
>
>Если для тебя не очевидно, что в случае CFS на графике одна
>и та же нагрузка перемещается с ядра на ядро считаю диспут
>с тобой законченным, ты не хочешь видеть очевидного. Имеющий глаза увидит.
>вот все так много книжек прочитали, а взять о поставить kernel debuger + да счётчики на breakpoint'ы а потом посчитать не всилах -- легче языком трепаться.
3 книжки говоришь ? отлично -- я думаю все будут рады увидеть конкретные данные а не болтовню типа "да у меня всё равно длиннее"
>вот все так много книжек прочитали, а взять о поставить kernel debuger
>+ да счётчики на breakpoint'ы а потом посчитать не всилах --
>легче языком трепаться.
>
>3 книжки говоришь ? отлично -- я думаю все будут рады увидеть
>конкретные данные а не болтовню типа "да у меня всё равно
>длиннее"$500 на WM кошелёк и договорились. От бесплатной работы даже кони дохнут.
>$500 на WM кошелёк и договорились. От бесплатной работы даже кони дохнут.за ночь или за час?
(интересно же сколько "кони" стоят...)
Тётя, я их тоже прочёл. + Клаудия Зальзберг Родригес, Гордон Фишерб и Стивен Смольски (Азбука ядра)
но видимо (в твоём случае) - это ничего не значит.Если ты не можешь объяснить свои же графики, также не можешь указать на кусок кода в ядре, где по твоим словам каждые 0,5c CFS переключает контекст выполнения с одного физического ядра на другой (чтобы жизнь мёдом не казалась, не иначе), а не в зависимости от нагрузки, то как говорится - слив засчитан.
>ТётяЗа это можно и по лицу получить в реале.
>Если ты не можешь объяснить свои же графики, также не можешь указать
>на кусок кода в ядре, где по твоим словам каждые 0,5c
>CFS переключает контекст выполнения с одного физического ядра на другой (чтобы
>жизнь мёдом не казалась, не иначе), а не в зависимости от
>нагрузки, то как говорится - слив засчитан.Ещё раз, для тех кто в танке искать в CFS я ничего тебе не обязан, размер кода сильно больше чем у BFS, сам ищи.
а ты думал только тебе можно применять унижительные обращения?
такшта, шёл бы ты со своими претензиями лесом.
>Ещё раз, для тех кто в танке искать в CFS я ничего тебе не обязан, размер кода сильно больше чем у BFS, сам ищи.т.е. твои слова:
> CFS постоянно с ядра на ядро перебрасывает. BSF же такого НЕ делает.просто голый трёп.
ну я уже писал - слив засчитан.
>С какого хера мой пост потёрли, аргументов не осталось кроме цензуры?
>
>Вот скриншот, ещё будешь утверждать, что CFS с ядра на ядро не
>гоняет?
>http://pobeg1980.livejournal.com/1941.htmlДля четкости - говорю о 10-й секунде графиков(правильней конечно все просуммировать/интегрировать на участке в 60 сек)...
Суммарная нагрузка системы на нижнем графике ~37.5%, а на верхнем ~43.75% - это говорит что система на нижнем графике при тех же задачах менее нагружена?
Я прав?
>Суммарная нагрузка системы на нижнем графике ~37.5%, а на верхнем ~43.75% -
>это говорит что система на нижнем графике при тех же задачах
>менее нагружена?
>Я прав?Полагаю дело обстоит так.
>>Суммарная нагрузка системы на нижнем графике ~37.5%, а на верхнем ~43.75% -
>>это говорит что система на нижнем графике при тех же задачах
>>менее нагружена?
>>Я прав?
>
>Полагаю дело обстоит так.Применим ли BFS на RT ядрах?
>Применим ли BFS на RT ядрах?Незнаю, код RT патча не смотрел. Нужно смотреть не пересекаются ли RT и BSF патчи. По идее теоретически это может вместе работать.
начнём с того, что этот код написан Инго Молнаром.... и завязан на планировщик.
>По идее теоретически это может вместе работать.смотря что.... ряд патчей, которые обработку прерываний просто запихнули в отдельные потоки (а не в очередь)... но опять же, как они будут обработаны. планировщик тут - важная вещь.
>начнём с того, что этот код написан Инго Молнаром.... и завязан на
>планировщик.
>смотря что.... ряд патчей, которые обработку прерываний просто запихнули в отдельные потоки
>(а не в очередь)... но опять же, как они будут обработаны.
>планировщик тут - важная вещь.Начнём с того, что после вчерашнего просмотра кода BFS сложилось впечатление, что Коливас выкинул внутренности CFS заменив своим кодом сохранив API.
>>Применим ли BFS на RT ядрах?
>
>Незнаю, код RT патча не смотрел. Нужно смотреть не пересекаются ли RT
>и BSF патчи. По идее теоретически это может вместе работать.Во многих конфигах ядер параметр CONFIG_NR_CPUS=64 - имеет ли смысл - для сборки с патчами BFS уменьшить этот параметр до значений, в которых BFS работает более эффективно например до 8?
>Во многих конфигах ядер параметр CONFIG_NR_CPUS=64 - имеет ли смысл - для
>сборки с патчами BFS уменьшить этот параметр до значений, в которых
>BFS работает более эффективно например до 8?Ненужно, всё что нужно в патче устанавливается. Там это откомментированно
а чего спорить-то, добавляли-бы все планировщики и давали возможность пользователю легко их переключать, пусть сам под свои задачи выбирает.
в винде и то что-то подобное есть.
а вот это правильно.
и шоб через граб можно было выбирать какой надо.
Верно! И чтоб ещё можно было выбирать частоту таймера шедулера(250, 300, 1000).
>Верно! И чтоб ещё можно было выбирать частоту таймера шедулера(250, 300, 1000).и ведь что смешно-то? что уже можно. зачем будущее время для того, что давно уже сделано — не понятно.
И это можно где-то переключать на ходу?
хотя сомневаюсь что из переключений можно извлечь что-то полезное...
Да... Инго взял такие типичные для декстоп систем задачи как сборка ядра и postgresql. Я прям каждый день на своём нетбуке ядра собираю, да хостинг кручу.
и что Вы предлагаете? выкинуть CFS?ps:
у меня на ноуте кластер из виртуалок с субд... у каждого своё понятие о десктопе.
но если ещё и сервера начнут тормозить, то... вендекапец не за горами.
pps:
а ведь он ещё и тюнится.
> и что Вы предлагаете? выкинуть CFS?А нафиг выкидывать то?
> у меня на ноуте кластер из виртуалок с субд...
ИМХО, мсье знает толк в извращениях :D
> а ведь он ещё и тюнится.
Угу, представь себе картину маслом - чайниковатые юзеры тюнят шедулер, ага. По-моему, они тогда BFS'ом назовут какой-то другой шедулер.
P.S. я так и не понял почему в вашем понимании десктоп по дефолту должен работать хуже чем мог бы и только с напильником и почему BFS не имеет права на жизнь как нечто опциональное, а там пусть майнтайнеры в меру своих понятий о применении их ОС думают. Не, не вариант?
>ИМХО, мсье знает толк в извращениях :Dтесты, экспиреенс,... денюжка в дом. а тут сразу и виртуализация, и кластеризация, и айскази (и пр. ай....)
>Угу, представь себе картину маслом - чайниковатые юзеры тюнят шедулер, ага. По-моему, они тогда BFS'ом назовут какой-то другой шедулер.пусть тюнят дистростроители - generic, server, rt, etc.
чуть выше специально дал описание бубунтовского rt-ядра. повторюсь:
>linux-image-2.6.28-3-rt ......
>Описание: Linux kernel image for version 2.6.28 on Ingo Molnar's full real time preemption patch (2.6.28-rt)к чему это я? и CFS, и real time preemption patch разработаны Ingo Molnar. последние вообще-то проходят обкатку и если всё пройдёт удачно и будет востребовано, то rt будет нормой для любого ядра. ну и напуркуа тогда BFS? (хотя я не против, чтобы можно было выбирать. ситуация в данном случае не такая, как с Рейзером)
>>ИМХО, мсье знает толк в извращениях :DНу да, а первый вопрос тактично не замечен :).Я честно говоря не вижу разумных причин выбросить один планировщик лишь потому что в состав ядра включен второй и мелкий.
>тесты, экспиреенс,... денюжка в дом. а тут сразу и виртуализация, и кластеризация,
>и айскази (и пр. ай....)И все это на ноутбуке :)))).Нет, я был прав в своих выводах, I'm sorry. Ну ладно я там еще на 4-ядерном десктопе с 8 гиг оперативы испытываю понятные желания попользоваться благами цивилизации и машиной с ресурсами приличного сервера как-то похитрее
>пусть тюнят дистростроители - generic, server, rt, etc.
Ага, вместо того чтобы сделать нормальное решение от правильных парней, надо нагородить кучу велосипедов :).В итоге получится куча багов и прочая. Мне кажется что пихнуть в ядро bfs не настолько большое зло (вплане распухона кода и прочая) как потенциальный глюкодром от такого местечкового велосипедострительства.
>и будет востребовано, то rt будет нормой для любого ядра. ну
>и напуркуа тогда BFS? (хотя я не против, чтобы можно было
>выбирать.Вот я и не понимаю - почему бы не воткнуть bfs до кучи, он что, такой здоровый и требует много изменений? Наверное в ряде применений как то всякие мелкие эмбеддед железки без всяких монстрильных постгресов, NUMA и прочая, но зато с дохлым процом в три комариные силы простой шедулер с минимальным оверхедом и обеспечивающий хорошую отзывчивость системы смотрелся бы правильным выбором.
>Ну да, а первый вопрос тактично не замечен :).конечно тактично. :-D
глупо отвечать на вопрос, который был дан как "ответ" на первоначальный.
>Ага, вместо того чтобы сделать нормальное решение от правильных парней, надо нагородить кучу велосипедов :).кто такие?
и о какой куче идёт речь?
насколько я понял - Вы за то, чтобы в эту кучку ещё пару планировщиков добавить?
или нет? Вы уж определитесь - должна эта куча расти или нет.
Зачем выкидывать? Просто для начала определиться с постановкой задачи. А то будет как в тестах фороникса - ежа с ужом, бобра с козлом.
вот чуть выше (34 коммент) описал задачу.
CFS и реалтайм смогут вполне конкурировать с BFS. и не только.
макос вот тоже рт. и тоже уже никс.
Бред, по производительности CFS и риалтайм вместе будут уступать BSF. В плане интерактивности различий не будет. Сейчас в ядре идёт активная работа по замене BKL (big kernel lock) на mutex и его фундамент futex. После зхавершенияэтой работы rt нужен будет только в сугубо специфических случаях, как обработка видео и т.п.
оба положения - не факт. а BKL ну вообще не в той опере где рт.
в любом случае - это определённая концепция... которой у BSF нет (хорошо если ещё чего не поломает... особенно того, что до этого отлично работало)зы:
впрочем ниже я писал, что было бы не плохо, если бы можно было выбирать при загрузке/компиляции ядра.
>оба положения - не факт. а BKL ну вообще не в той опере где ртРечь не о принципах обеспечения rt, а о сравнении CFS и BSF и цели написания BSF. Коливас пишет, что его достали замирания курсора мыши и невозможность на 100% всю мощь многоядерных процессоров. на графиках Коливаса это прекрасно видно, CFS только начиная с большого количества потоков начинает распределять ресурсы ядер полноценно. Так вот замирания курсора мыши следствие BKL. РТ же не может дать той производительности, что BSF так по понятным причинам будут накладные расходы.
>в любом случае - это определённая концепция... которой у BSF нет
Которая BSF не нужна, цели написания BSF описаны выше. Нужен RT ставь rt ядро/патч.
>(хорошо если ещё чего не поломает... особенно того, что до этого отлично работало)У меня всё пашет, как часы на BSF.
а я вот разницы не заметил. что так, что так - визуально одно и тоже - может квалификация не та, а может лень меряться, искать линейки-методики :-D, а графики (как видим - у всех разные), слова... кстати, о словах:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...
>This is the CFS scheduler. 80% of CFS's design can be summed up in a single sentence: CFS basically models an "ideal, precise multi-tasking CPU" on real hardware. "Ideal multi-tasking CPU" is a (non-existent :-)) CPU that has 100% physical power and which can run each task at precise equal speed, in parallel, each at 1/nr_running speed. For example: if there are 2 tasks running then it runs each at 50% physical power - totally in parallel.так что, из 2-х вариантов я выберу тот, что без приключений на пятую точку. хоть и посмотрю на альтернативы (по возможности)
и ничего в ответ... всё равно поясню :-D:
1. Con Kolivas разработал свой планировщик BFS для лучшей отзывчивости системы (а не для 100% мощи, как говорит Дохтур выше).
и это понятно - лично на моём ноуте проц(ы) 95% времени висит на частоте 800MHz.2. для 100% мощи Ingo Molnar как раз разработал планировщик CFS
см. цитату чуть выше и графики от него самого в топике - подтверждение, которое и Con Kolivas вроде не опровергает.3. рт также способствует увеличению отзывчивости. при объединение его с CFS.
(ах да! увеличение нагрузки на проц! интересно, а как быстро я замечу разницу, когда мой десктоп на 800Mhz будет проводить не 95%, а 93% времени?)
> Результаты исследования представлены на четырех графиках: kbuild
> (производительность сборки ядра Linux), (hackbench - производительность
> обмена сообщениями), oltp (postgresql + sysbench), pipe (скорость
> обмена данными через pipe).Оригинально. Они там что, шлангами прикидываются? CK написал планировщик для десктопа. И более идиотских бенчмарков для ДЕСКТОПА чем перечисленное я затрудняюсь себе представить. Интересно, а что мешает включить этот планировщик как опциональный и не пользоваться им для упомянутых задач?
> что мешает включить этот планировщик как опциональный и не пользоваться им для упомянутых задач?Из серии: Что мешает переходу на GPLv3?
Политика. Кон - он как бы анестезиолог, а не программист. Каково линусу и монлару осознавать, что один анастезиолог делает для десктопа в linux больше, чем два программиста?
Кроме того есть ещё принцип "жопе слова не давали". Если Кон обретёт признание, у него не будет надобности проталкивать свой код, и освободится время на то чтобы толкать свой взгляд на вещи. А это нонконформизм, который линусу и его фанатикам не нужны.
>Политика. Кон - он как бы анестезиолог, а не программист.Простите, не-программисты не могут написать такой шедулер, по определению. Является ли этот род деятельности full time или нет - не так уж и важно, человек программист если он умеет программировать. А программирует ли он час в день, 2 часа или 8 - это уже его дело. Давайте еще откажем в звании музыканта всем тем кто не играет музыку с утра до вечера? oO
>Каково линусу и монлару осознавать, что один анастезиолог делает для десктопа в linux
>больше, чем два программиста?В глобальном плане у них может быть своя логика - как то данный шедулер сливает в других задачах (что не есть гуд).А тянуть добавочный код в ядро наверняка резонно не хочется(там и так шыта навалом).Выбросить совсем одно в пользу другого опять же не вариант судя по бенчам и тому что автор сам не скрывает что его шедулер полезен далеко не везде. До того как говорить политика надо рассмотреть логику всех сторон. Разве нет?
>А это нонконформизм, который линусу и его фанатикам не нужны.
Вообще, команда работающая над проектом все-таки должна действовать согласовано и желательно без выяснений у кого длиннее и грызни и пикировок, иначе ничего хорошего не выйдет. Басню лебедь, рак и щука знаете? Кто-то впишется, кто-то нет. Такова жизнь. И делать трагедию или клоунаду из очевидных (но видимо не всем?) вещей как-то инфантильно.
Но вот Молнар искренне удивил своей аргументацией. То что CK его нелестно заткнул - логичное следствие. Итого я вижу простую как топор ситуацию - Молнар протупил (в лучшем случае), на что CK резко ответил. При том резкость до некоторой степени понятна. До некоторой, да. Но вообще, если бы люди были сдержаннее, их сосущетвование было бы намного приятнее.
> человек программист если он умеет программироватьсмешно звучит... как будто программирование это религия и если ты умеешь молиться компьютерному богу значит ты программист :-)
но вообще с автором согласен умеешь программировать значит программист, а есть такие которые и учились этому и программируют, но лучше бы они этого не делали
> Является ли этот род деятельности full time или нет - не так уж и важноОчень важно. Линус по сути чиновник. Если чиновнику обосновать что ты можешь делать его работу лучше его подчинённых, он рад не будет.
> тянуть добавочный код в ядро наверняка резонно не хочется(там и так шыта навалом)
1. Если там и так навалом шита, будет ли хуже от ещё небольшой капельки?
2. Их никто не просил никуда ничего добавлять. Им спецом отдельно сказали что их шедулер не касается и поддерживаться будет без них.
> Вообще, команда работающая над проектом все-таки должна действовать согласовано и желательно без выяснений у кого длиннее и грызни и пикировок, иначе ничего хорошего не выйдет.
Да я уж со счёта сбился сколько народу с линусом разосралось и бросило поддерживать код. Хорошая у него комманда, только код виндой и рефакторингом уже попахивает.
> если бы люди были сдержаннее, их сосущетвование было бы намного приятнее
Проблема далеко не в сдержанности, а в неадекватном положении линуса и монлара (см. басню "кукушка и петух"). И Кон это прекрасно понимает, так что смысла как-то сдерживаться нет.
>Очень важно. Линус по сути чиновник. Если чиновнику обосновать что ты можешь
>делать его работу лучше его подчинённых, он рад не будет.Он не чиновник. Он - project manager огромного проекта. Это нереально геморная должность с огромной ответственностью.Потому что ряд промахов - и бац - вы уже в шкуре капитана Титаника, наблюдающего как недавно еще вполне живой проект идет ко дну и пускает пузыри. Ну а хороший капитан - прибывет в порт назначения без приключений. Торвальдс за столько лет доказал что он - хороший капитан. И - да, иногда таким людям приходится принимать не самые простые решения и сталкиваться с не особо приятными вещами. И в конце концов - это капитанское дело - какие решения принять и кого набрать в матросы.
>1. Если там и так навалом шита, будет ли хуже от ещё
>небольшой капельки?Будет, разумеется. Один подвалит, другой подвалит... как известно, из капель собираются реки. Так что в итоге получится обычная такая глюкавая монстрила.
>2. Их никто не просил никуда ничего добавлять. Им спецом отдельно сказали
>что их шедулер не касается и поддерживаться будет без них.Но ведь сказали же. А значит они в своем праве высказаться. Другое дело что Молнар использовал эту возможность весьма странно.
>Да я уж со счёта сбился сколько народу с линусом разосралось и
>бросило поддерживать код.И что? В целом - орава народа пашет, команда ядерщиков - есть. А на вообще всех 1 фиг не угодишь и некоторые будут друг с другом сраться. И как бы если вы считаете что сможете лучше - можете попробовать, как бы законом не запрещено. Проблема только в том что у 99.9(9)% людей потянуть проект такого уровня кишка тонка. Ругать можно, а толку? Есть железная уверенность что [некто] поставленный в те же условия выступит лучше Торвальдса? У меня на этот счет большие сомнения. Во всяком случае что-то я других столь же успешных руководителей проектов не вижу на каждом углу. Покажите их - тогда поверю.
> Хорошая у него комманда, только код виндой и рефакторингом уже попахивает.
Странное у вас чувство обоняния. И опять же - никто никому ничего не должен. Торвальдс делает так как ему удобно. Если вам не нравится - пытаетесь делать лучше, валите на что-то иное или там как вам удобно. А Торвальдс делает свое дело. Как умеет. Кому по вкусу - пользуется. Кому не по вкусу - не пользуется. Вроде просто все. Если утверждается что можно и лучше - так докажите. А то пока что доказательств не вижу чего-то. Как максимум можно попробовать указать на промахи. Тактично по возможности. А вот с нахрапом требовать их устранения - не выйдет. А кто вы, чтобы пытаться другим приказывать что им *требуется* делать? Можете *посоветовать*, желательно аргументированно. Не более.
>Проблема далеко не в сдержанности, а в неадекватном положении линуса и монлара
Неадекватном?! Торвальдс создал этот проект и развил его до состояния в котором оно сейчас. А тут приходите вы и заявляете что у него неадекватное положение? Интересное кино. Да, не без помощи других. Но не будь Торвальдса - все могло бы быть совсем иначе. А кому не нравится положение и состояние дел как бы в своем праве форкнуть например, или действовать как им там удобно. Ну там свою команду создать, написать что-то с нуля и лучше, использовать что-то иное и еще два зиллиона вариантов. Какие проблемы то?
>смысла как-то сдерживаться нет.
А это зависит от того какие цели и какие результаты хочется получить.
Кстати да, если люди сработались - совершенно нормальная ситуация что один человек пытается прикрыть коллегу при нападках на него. Моя точка зрения - не совсем правы обе стороны. Если CK не хотел пикировок, стоило бы быть сдержаннее и вести себя иначе. А Молнар просто толи протормозил, толи воспринял это как булыжник в свой огород. В общем хрень какая-то.
Похоже, Инго в танке или броневике.
>Похоже, Инго в танке или броневике.Если быть точнее, Он на броневике. :)
Мёд, срач двух луноходов это просто мёд :)
Тесты Инго меня абсолютно убедили только в одно, что надо подаваться в разработчики ядра если у них у всех такие десктопы как в его тестах: 2-х процессорные четрыехядерники с гиперсредингом :-) (наверное не зря и Колин туда рветься :-) )а по существу:
даже на этих 2-х процессорных как двигалась мышка и можно ли было просматривать фильму во время таких тестов?
> даже на этих 2-х процессорных как двигалась мышка и можно ли было просматривать фильму во время таких тестов?Я удивлю некоторых и скажу: Можно!
Но!
У меня ноут, на ноуте два ядра. Каждое ядро по умолчанию работает с пониженным энергопотреблением. В условиях CFS задача скачет с одного ядра на другое и linux-у приходится постоянно повышать частоту на одном из ядер (на другом автоматом понижать). Такой перескок с повышением частоты длиться от половины секунды.
Так что: приходится в ручную задавать тактовую частоту максимальной при просмотре фильмов, при запуске флеша или для любой другой ресурсоёмкой задачи. Это автоматом означает п-ц заряду в батарейке.
При ситуации на рынке когда от 40% покупателей компьютеров покупают именно ноуты это ОЧЕНЬ критичный фактор. И на него линусу и монлару наплевать. Из-за гонора или из-за того что им приплачивают микросовтовцы - х.з., но неадекват на лицо.
