Вышло ядро 2.6.31

> у меня тоже самое, значит это не из-за BFS

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

> В процессе: R6XX, R7XX

Сраное говно. Неужели в Squeeze нормальная поддержка так и не попадет? :(

> du -sh linux-2.6.31 3,7G O_O

Чем дальше в лес - тем толще партизаны..

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

пацанчик, если зайдёшь в мой блог увидишь график сравнения cfs vs bsf, он был сделан на 2.6.30.2. А теперь подумай, самосборное оно или нет?

> надобно перелезть с 2.6.29 [...] из-за использования свободного драйвера под R500

Угу, только надо ставить свежайший драйвер radeon для Xorg. Потому как текущий не работает с ЭТИМ ядром :-)

> У меня Гномоапплеты и Гномодесктоп отвалились. Пробовал починить, не помогло. Думаю к кому обращаться.

Напиши об этом на kde.org
Наверняка что-нибудь дельное присоветуют

> ПО глубоко зависит от ядра и могут быть проблемы?

На практике да, хотя теоретики будут утверждать обратное.

> пацанчик, если зайдёшь в мой блог увидишь график сравнения cfs vs bsf, он был сделан на 2.6.30.2. А теперь подумай, самосборное оно или нет?

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

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

>Может, вы бубунтоиды, которые собрали ядро с крутым патчем, но без initrd,

Лол.А поцчему вы считаете что в Убунте ядро без инитрд быть не может?

> Лол.А поцчему вы считаете что в Убунте ядро без инитрд быть не может?

А оно там есть? Чтоб с "дефолтным конфигом" и без initrd. Пруфлинк приветствуется.

>Чтоб с "дефолтным конфигом" и без initrd.

А кто говорит про дефолтный конфиг?Или вы только с дефолтным умеете?

>Ну, я просто спросил, зачем так болезненно реагировать

Это не болезненно, это обычный словесный оборот там где применяют слово _пацан_.

>Может, вы бубунтоиды, которые собрали ядро с крутым патчем, но без initrd, например, и вам нет пути.

Всё мы собрали чётко,только проблема в самой Ubuntu alpha 5, не грузиццоо с новым ядром.

>Не буду же я по бложикам всех местных пацанов ходить.

Правильно. могут на мобилку заиграть, а потом за базар отвезти.

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

Реальные пацаны чётко просекают, что CFS раз в 250 миллисекунд производит балансировку потоков вызывая load_balase(), которая в свою очередь отключает обработку IRQ и балансирует на остальные ядра потоки из очереди потоков текущего ядра, причём не более 32 за раз и только если есть очередь в которой на 25% и более больше потоков чем в текущей. Причём сначала балансируются очереди спящих потоков и только в отсутствие таковых очереди исполняемых потоков. Что собственно прекрасно видно на графике CFS. У BFS же в реале всё ровно.

вызывая load_balance()

next-20090910 - это типа новая версия ядра? Они теперь так именоватся будут?

Уррааа!!!!

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

Ага, выше написал.

> А кто говорит про дефолтный конфиг?Или вы только с дефолтным умеете?

http://www.linux.org.ru/jump-message.jsp?msgid=4031027&cid=4031937

>Напиши об этом на kde.org

Каков будет третий совет? )

Не-не, я уже давно излечился. Просто иногда бывают рецидивы. :)

>http://www.linux.org.ru/jump-message.jsp?msgid=4031027&cid=4031937

Ну так туда б и адресовали свои высказывания, а не проводили б необоснованные обобощения.Алсо, автор цитаты не писал про Убунту, дефолтные конфиги много где.

мда,проблема оказалась не в BFS а во мне, точнее mkinitcpio -g /boot/initrd.img -k 2.6.31

> Реальные пацаны чётко просекают, что CFS раз в 250 миллисекунд производит балансировку потоков вызывая load_balase(), которая в свою очередь отключает обработку IRQ и балансирует на остальные ядра потоки из очереди потоков текущего ядра, причём не более 32 за раз и только если есть очередь в которой на 25% и более больше потоков чем в текущей. Причём сначала балансируются очереди спящих потоков и только в отсутствие таковых очереди исполняемых потоков. Что собственно прекрасно видно на графике CFS. У BFS же в реале всё ровно.

Ровные полосочки - и что? О чем это должно нам говорить? Если просуммировать линии CFS, в итоге тоже все получится ровно. Какая мне должна быть разница, одинаково загружены оба ядра или загрузка симметрично плавает? Любому лоху должно быть понятно, что минималистичный шедулер будет минималистично менять уровень загрузки ядра при постоянной нагрузке, но в чем самоценность прямой линии, мне не совсем понятно, например. В DOS'е она вообще всегда идеально ровная. Это нереально круто?

Сравнивать работу шедулеров по картинкам загруженности ядер - это примерно такое же глубокомысленное занятие, как делать далеко идущие выводы о качестве кодирования в MP3 по получаемым гистограммам. Хотя, пожалуй, нет, ваши исследования я нахожу еще более сферичными.

атишников этим не напугать =)

> А оно там есть? Чтоб с "дефолтным конфигом" и без initrd. Пруфлинк приветствуется.

С дефолтным никак. Зато со своим конфигом любое ядро с Ubuntu хорошо работает...

>Ровные полосочки - и что? О чем это должно нам говорить? Если просуммировать линии CFS, в итоге тоже все получится ровно. Какая мне должна быть разница, одинаково загружены оба ядра или загрузка симметрично плавает? Любому лоху должно быть понятно, что минималистичный шедулер будет минималистично менять уровень загрузки ядра при постоянной нагрузке, но в чем самоценность прямой линии, мне не совсем понятно, например. В DOS'е она вообще всегда идеально ровная. Это нереально круто?

Я уже имел спор с таким же как ты на opennet.net на эту тему. Не стобой ли? Вот тебе постулаты, покури над ними.

1. Усреднённая загрузка СFS будет выше чем BFS. Ты бы не спорил тут голословно а взял и посчитал путём сложения величин и деления на количество ядер. Там даже на глаз видно, что у CFS средня величина загрузки на проценов на 5%-10% выше, смотри точку 10 секунд.

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

3. Тебе нереально крутому лошпету должно быть известно, что DOS это НЕ многозадачная операционка и никакого шедулера там нету. Так что ты ту пёрнул в лужу.

4. В отличии от тебя форумной балаболки, я смотрел код и CFS, и BFS. Ты же только посмотрев график газифицируешь лужи.

> Думаю, все уже бегут и падают делать проксирование через pulseaudio...

Так вроде уже сделали. Или я что-то не понял?

Кстати говоря, буквально позавчера во время флейма CFS vs BFS в LKML'е нашли и вроде бы пофиксили регрессию в CFS.

>Кстати говоря, буквально позавчера во время флейма CFS vs BFS в LKML'е нашли и вроде бы пофиксили регрессию в CFS.

Ещё одно подтверждение лучше раздачи ресурсов BFS. Ну ужд после этого вопросы то отпадут интересно?!

>Добавлен новый интерфейс CUSE ... И чем теперь ALSA лучше OSS?

В karmic же оно будет?

Не! Там будет 2.6.29

Хорошая новость.

> Я уже имел спор с таким же как ты на opennet.net на эту тему. Не стобой ли? Вот тебе постулаты, покури над ними.

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

> 1. Усреднённая загрузка СFS будет выше чем BFS. Ты бы не спорил тут голословно а взял и посчитал путём сложения величин и деления на количество ядер. Там даже на глаз видно, что у CFS средня величина загрузки на проценов на 5%-10% выше, смотри точку 10 секунд.

Это ты проводил исследования и "BFS отчётливо грузит равномерно оба ядра, CFS рисует кривую как при сердечном приступе." - это твой главный вывод, и он не про загрузку, так что не надо переводить стрелки. Кстати говоря, мне не видно на твоем графике разницы общей загрузки в 5%-10%, а что касается некоторых отдельных моментов, я с легкостью найду несколько таких, где CFS показывает меньшую загрузку.

> 2. При перемещении работающих потоков с ядра на ядро, а это в случае CFS вполне реально, падает производительность т.к. количество пападаний в кеш сокращается до нуля для текущего потока.

Опять сферические теории? Для этого вообще можно было не рисовать никаких графиков.

> 3. Тебе нереально крутому лошпету должно быть известно, что DOS это НЕ многозадачная операционка и никакого шедулера там нету. Так что ты ту пёрнул в лужу.

Зато там есть загрузка процессора, и она идеально ровная. Не надо приписывать мне того, о чем я не говорил.

> 4. В отличии от тебя форумной балаболки, я смотрел код и CFS, и BFS. Ты же только посмотрев график газифицируешь лужи.

Смотрел-то не вверх ногами? Тогда это уже само по себе круто, чувак, базара нет! Извини, но я показываю тебе на пузыри в твоей луже, а ты огрызаешься.

Все до одной отмазки гнилые.

а если ядро одно, есть смысл в BFS?

lsmod | grep acer
acer_wmi 19304 0
rfkill 13108 5 iwlcore,acer_wmi
led_class 5112 2 iwlcore,acer_wmi
wmi 7968 1 acer_wmi

uname -r
2.6.30-ARCH

to Robotron :

> 2. При перемещении работающих потоков с ядра на ядро, а это в случае CFS вполне реально, падает производительность т.к. количество пападаний в кеш сокращается до нуля для текущего потока.

а теперь объясни как 2 независимых процесса, если каждый будет работать на своём ядре, будут загружать эти ядра одинакого ? случаем не сильно ли страдает BFQ в данном случае перекидыванием потоков между ядрами ?

Готово! ~$ uname -a Linux core 2.6.31-bfs211-bfuck #1 SMP PREEMPT Thu Sep 10 15:35:07 ALMT 2009 i686 GNU/Linux

Последнее ядро и свежий патч. Ubuntu 9.04, дрова на nvidia 190.18

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

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

Для начала, я тебе ничего не должен, ни объяснять ни тому подобное, могу и послать если что.

Далее, BFQ тут страдать не будет потому, что только полный профан в планировщиках мог спутать предмет спора, а именно BFS и BFQ.

Далее, насколько я понял из кода BFS он с ядра на ядро не перекидывает работающие потоки, а запускает равномерно спящие потоки на ядрах, причём квант времени потока при BFS меньше чем у CFS.

И ещё далее поскольку квант времени BFS меньше какой либо визуально различимой величины, на графике ты видишь почти прямую линию.

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

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

Т.е. анализ кода планировщика это теория?! Однако. Т.е. нельзя сказать по коду что тут происходит и по комментариям к коду тоже?! Как же тогда люди программы то пишут если код трактовать однозначно нельзя?!

А все-таки, на одноядренном будет толк?

>А все-таки, на одноядренном будет толк?

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

ну, вот и дождались!

минорный релиз ^^

А для двух ядер будет толк?

Ждём когда чёткие пацанчиги из http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu соберут ядро со всеми патчами и дровами.

>А все-таки, на одноядренном будет толк?

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

од чорт , у меня athlon 3500+ c одним ядром. Нужно покупать феном с 3-4 или 8 ядрами и ставить планировщиком BFS ... шоб не тормозил падлюка когда я кино смотрю (чего там на десктопах еще разрешают делать чтоб графики хорошие были?) .

Я один не рад >_< почему R6xx только в процессе??? Radeon HD2400 Pro с собранной Mesa7.5.1 греется как писька

Так, похоже, у всех ядро собралось из ванильных исходников, и только
у меня оно не собралось. А использовал я .config 2.6.30.5 через make
oldconfig. Вот что имею после выполнения:

time make-kpkg --rootcmd fakeroot --initrd kernel_image kernel_headers

...
IHEX2FW firmware/keyspan_pda/keyspan_pda.fw
IHEX2FW firmware/keyspan_pda/xircom_pgs.fw
make[1]: Leaving directory `/home/andrey/progs/kernel/linux-2.6.31'
/usr/bin/make ARCH=i386 \
-C Documentation/lguest
make[1]: Entering directory `/home/andrey/progs/kernel/linux-2.6.31/Documentation/lguest'
cc -m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE lguest.c -o lguest
lguest.c:21:25: error: sys/eventfd.h: Нет такого файла или каталога
lguest.c: In function ‘create_thread’:
lguest.c:1021: warning: implicit declaration of function ‘eventfd’
make[1]: *** [lguest] Ошибка 1
make[1]: Leaving directory `/home/andrey/progs/kernel/linux-2.6.31/Documentation/lguest'
make: *** [debian/stamp/build/kernel] Ошибка 2

real 103m9.328s
user 93m20.246s
sys 6m41.417s

(при этом 2.6.30.5 собиралось таким же образом без проблем)

/me поскакал собирать...
А планировщик анестезиолога в эту версию не добавили?

посмотрело на всех ... и зашло.

> А планировщик анестезиолога в эту версию не добавили?

Если анестезиолог замочит текущего сопровождающего планировщика ядра, Лайнус сразу включит его планировщик, а так не дождетесь. Решения Лайнусу даются свыше.