форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Автор CFS провел исследование производительности планировщик..."	+/–
Сообщение от opennews on 07-Сен-09, 08:40
Инго Молнар (Ingo Molnar), известный разработчик Linux ядра и автор планировщика задач CFS (Completely Fair Scheduler), ответил (http://groups.google.com/group/linux.kernel/msg/35ee2ca58bbe...) на заявление Кона Коливаса (Con Kolivas) о выпуске (http://www.opennet.dev/opennews/art.shtml?num=23249) нового, простого и быстрого планировщика BFS, серией экспериментов по оценке производительности. Между Коном и Инго установились довольно напряженные отношения, Кон с 2002 года поддерживал разработку O(1) планировщика задач SD (Staircase Deadline CPU scheduler), но его код постоянно откладывался для включения в состав Linux ядра, а в 2007 году Линус Торвальдс отдал предпочтение (http://www.opennet.dev/opennews/art.shtml?num=11572) планировщику CFS (http://www.opennet.dev/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.dev/opennews/art.shtml?num=23313
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Автор CFS провел исследование производительности планировщик..."	+6 +/–
Сообщение от DFX on 07-Сен-09, 08:40
4096 ядерные компы такие 4096 компы. Кон с самого начала заявлял что делает планировщик с уклоном на уменьшение задержек в _ущерб_ производительности. ещё бы - в 1\2\4 процессорных\ядерных системах чего больше - мегагерц или процессов ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Автор CFS провел исследование производительности планировщик"	–3 +/–
Сообщение от Просто Лось. on 07-Сен-09, 08:41
Инго очень старался быть вежливым, молодец. А вот ответ Кона граничит с хамством.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Автор CFS провел исследование производительности планировщик"	+6 +/–
	Сообщение от victor (??) on 07-Сен-09, 08:54
	1. вынести выговор с записью в личное дело. 2. премию за планировщик не выплачивать. за предложенные меры прошу голосовать
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	12. "Автор CFS провел исследование производительности планировщик"	+2 +/–
	Сообщение от empty on 07-Сен-09, 10:30
	>> Инго очень старался быть вежливым Ну, дык, Торвальдс это тоже оценил.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	43. "Автор CFS провел исследование производительности планировщик"	+2 +/–
	Сообщение от Аноним (??) on 07-Сен-09, 16:18
	> Инго очень старался быть вежливым, молодец. > А вот ответ Кона граничит с хамством "Автор BFS провел исследование производительности планировщика задач СFS" И выяснил что положение с CFS закритическое. И кто после этого граничит с хамством?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Автор CFS провел исследование производительности планировщик..."	+1 +/–
Сообщение от birdie on 07-Сен-09, 08:43
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.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	45. "Автор CFS провел исследование производительности планировщик..."	+2 +/–
	Сообщение от Аноним (??) on 07-Сен-09, 17:02
	>> CK какой-то грубый стал (или мне показалось). Показалось. Кон предположил несколько пунктов: 1. Инго невнимательно прочитал FAQ (bfs-faq.txt). Или внимательно, но цель написания BFS, указаную в FAQ, проигнорировал. 2. В очередной раз (имеется ввиду шедулеры написанные ранее) Инго подобрал тесты выгодные для утверждения того что CFS круче. Исходя из этого, Кон иронично намекает, что Инго вообще не знает как выглядит десктоп ПК и не представляет чем обычные люди на нем занимаются. И под конец, разъясняет "для тупых": - проверяю прогресс в клиенте распределенных вычислений, запускаю следующее H264 кодирование, переключаю музыкальные треки и готовлюсь быть порванным на quakelive.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	48. "Автор CFS провел исследование производительности планировщик..."	+1 +/–
	Сообщение от User294 (ok) on 07-Сен-09, 19:56
	По-моему, втереть про левые тесты которые не очень то относятся к ДЕСКТОПАМ когда человек сделал шедулер для десктопов - тоже не очень то вежливо? Да, можно сказать что микросоп - хреновый молоток. Но поставить это в минус его создателям - не катит.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Автор CFS провел исследование производительности планировщик..."	+5 +/–
Сообщение от iZEN (ok) on 07-Сен-09, 08:43
Кон Коливас создал BFS не для производительности. А для лучшей интерактивности (грубо говоря: чтобы курсор мыши на экране пользователя не замораживался во время сильной загрузки CPU). Производительность — это другое, не первостепенный аспект на десктопах.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Автор CFS провел исследование производительности планировщик..."	–5 +/–
Сообщение от mma on 07-Сен-09, 08:56
какой толк от этих графиков на десктопе. лучше бы Кон сделал репозитарии для дебиана убунты федоры с собранным ядром с его планировщиком - а юзеры уже сами бы оценили.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	156. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Аноним (??) on 09-Мрт-14, 21:42
	Нахрена программеру, ядерному хакеру, заниматься сборкой ядра для твоего Дебиана? Этим другие должны заниматься - сообщество, которое должно было по идее образоваться вокруг патчей Кона Коливаса, но его нет почему-то. Почему - не могу ответить ибо меня это мало волнует. Хочешь - возьмись ты за это дело, заодно сделаешь что-то полезное для своего дистрибутива.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

7. "Автор CFS провел исследование производительности планировщик..."	+1 +/–
Сообщение от morten on 07-Сен-09, 09:00
Коливас ответил грубо, но по делу. Тем более, что у Инги радушие лицемерное. Впрочем, лично мне на десктопе CFS нравится даже без спецтюнинга.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Автор CFS провел исследование производительности планировщик..."	+/–
Сообщение от J10 on 07-Сен-09, 09:57
холивары на уровне разработчиков... цирк
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Автор CFS провел исследование производительности планировщик..."	+1 +/–
	Сообщение от vitek (??) on 07-Сен-09, 10:10
	это называется конкуренция. а цирк... это лучше у внедренцев-консультантов поспрашать. как не работающие блобы годами внедряют.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

13. "Автор CFS провел исследование производительности планировщик..."	–1 +/–
Сообщение от poige (ok) on 07-Сен-09, 10:39
BFS слишком сырой пока, и я лично уже это заметил на практике. CFS вполне нормально работает. Если кому-то нужны улучшенные интерактивности -- есть linux-rt.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Автор CFS провел исследование производительности планировщик..."	+2 +/–
	Сообщение от fidaj (ok) on 07-Сен-09, 11:39
	Открою небольшую тайну - там (на linux-rt) тоже те же планировщики, что и не у -rt и ой как CFQ вешало систему при больших дисковых операциях (iowait непомерно росло) включая ядро 2.6.24-rt - потом выпустили патч - патчил пока не надоело - потом перешел на ядро 2.6.29-rt где патч включили - потом ядро убрали из репов убунту...;) Так что я бы не хвалил CFQ! Он не на много НЕ сырее...
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	19. "Автор CFS провел исследование производительности планировщик..."	–1 +/–
	Сообщение от vitek (??) on 07-Сен-09, 11:56
	Вы хоть его правильно напишите для начала - 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)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	24. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от fidaj (ok) on 07-Сен-09, 12:06
	>[оверквотинг удален] > >са-а-а-фсем другая шняга. >зы: >рантаймовское ведро с медубунтой - полет нормальный >$ 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
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	25. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 07-Сен-09, 12:24
	ио-шедулер - вещь интересная. не скажу, что мне реализация сильно нравиться, но..... к релизам серверных дистров исправиться.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	31. "Автор CFS провел исследование производительности планировщик..."	+1 +/–
	Сообщение от User294 (ok) on 07-Сен-09, 13:27
	>Так что я бы не хвалил CFQ! Он не на много НЕ сырее... Перепутать планировщики CFQ и CFS - это эпично :)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

17. "Автор CFS провел исследование производительности планировщик..."	+/–
Сообщение от vl (??) on 07-Сен-09, 11:45
я лично поставил BFS на gentoo-sources-2.6.30-r6, kde стартанул и все повисло, но я возможно не правильно, что сделал, так как при патчение он ругнулся на два места, сказал, что патч уже есть. Лично считаю, что Инго сравнивал не то, Кон же написал для десктопа. А хамить не хорошо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Автор CFS провел исследование производительности планировщик..."	+2 +/–
	Сообщение от vitek (??) on 07-Сен-09, 12:00
	>А хамить не хорошо. не хорошо. но к шедулерам это отношения не имеет. Линус тоже за словом в карман не лезет. едиственный критерий качество кода, идеи, необходимости.... ну как-то так.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	26. "Автор CFS провел исследование производительности планировщик..."	+3 +/–
	Сообщение от Doctor (??) on 07-Сен-09, 12:34
	Поставил BSF на ядро 2.6.30.2 в ubuntu 9.10 beta 5. Всё работает идеально, по ощущениям минимум НЕ медленнее CFS. Моё мнение, для малоядерных процов (до 8) на десктопах стоит делать выбор в пользу BSF.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	28. "Автор CFS провел исследование производительности планировщик..."	+1 +/–
	Сообщение от Doctor (??) on 07-Сен-09, 12:52
	Да, есть вопрос. Вот CFS специально пытается грузить сначала одно ядро по полной и подключать второе только когда необходимо, и при этом в реальном времени процессы бросает каждый раз на новое ядро т.е. получается что ядро 0 загружено, а ядро 1 пустует через секунду или около того ядро 0 пустует а ядро 1 загружено теми же самыми процессами. BSF грузит оба мои ядра равномерно, без перетасовки. В чём смысл этих пертурбаций от CFS?
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	50. "Автор CFS провел исследование производительности планировщик..."	+1 +/–
	Сообщение от аноним on 07-Сен-09, 20:59
	на intel atom а также на power pc если загрузить только одно ядро получается немного быстрее чем раскидывать эту же задачу по двум ядрам. А еще на всех процессорах с необщим кешем ядер например на Athlon, лучше грузить только одно ядро, пока возможно.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	54. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от ТТТ on 08-Сен-09, 09:26
	Вообще то это не совсем так. Теория говорит всего лишь что не стоит перебрасывать часто один процесс с процессора на процессор если задачи 2 то лучше запускать их на разных процессорах что бы одна задача заполнила кеш одного процессора и работала оптимально а другая другого. но хотя с развитием многоядерности и кешев третьего уровня это преймущество немного скрадывается, но все еще остается.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	58. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 11:51
	Т.е. CFS для intel Atom, Athlon и прочих процов с малым кэшем заведомо будет более тормозным т.к. CFS постоянно с ядра на ядро перебрасывает. BSF же такого НЕ делает.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	59. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 14:39
	>CFS постоянно с ядра на ядро перебрасывает. Вы сами себе противоречите - то он у Вас только один проц по максимуму грузит, то перебрасывет. определитесь уж.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	61. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 15:22
	>Вы сами себе противоречите - то он у Вас только один проц по максимуму грузит, то перебрасывет. определитесь уж. Млять, специально для тех кто в танке ещё раз. CFS пытается исполнять на одном ядре, но через определённый квант времени где-то 0.5-1 сек перебрасывает всё на другое ядро физическое ядро. У CFS нет равномерной одномоментной загрузки обоих ядер, у CFS в определённый момент обычно занято обычно одно ядро (только в случае необходимости подключается второе ядро), но это первое занятое ядро через квант времени меняется на другое. Запусти в гноме системный монитор и график загрузки проца посмотри.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	62. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 16:02
	специально для тех, кто в окопе: 1. видимо именно поэтому этот планировщик и обгоняет. 2. пруфлик из окопа тяжко достать, но всё-таки попробуй. 3. ему, сцуко, занятся больше не чем, вот он и бросает их туда и обратно. зы: >у CFS в определённый момент обычно занято обычно одно ядро (только в случае необходимости подключается второе ядро) сцуко, htop мне постонянно врёт видимо. atop и пр. - тоже.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	64. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 16:58
	С какого хера мой пост потёрли, аргументов не осталось кроме цензуры? Вот скриншот, ещё будешь утверждать, что CFS с ядра на ядро не гоняет? http://pobeg1980.livejournal.com/1941.html
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	66. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 17:04
	гы-ы-ы-ы: первое. >BSF отчётливо грузит равномерно оба ядра, CFS рисует кривую как при сердечном приступе. В обоих случаях одна и та же нагрузка - firefox с плагином mplayer показывает из инета ТВ, totem показывает локальный фильм и htop для контроля. Показания htop и гномовского системного монитора совпадают. что доказывает только одно - на каждом проце при CFS работает СВОЙ поток, со СВОЕЙ нагрузкой. и если потребление ресурса (тут ЦПУ) не равно 100%, то выравнивания (переброса потоков на другие ЦПУ) не происходит. второе: и вот это - http://pobeg1980.livejournal.com/1941.html - пруфлинк??????? зы: я конечно определённо не девочка.... зачем озвучивать очевидное. плохо с воспитанием?
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	67. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 17:09
	>что доказывает только одно - на каждом проце при CFS работает СВОЙ поток, со СВОЕЙ нагрузкой. и если потребление ресурса (тут ЦПУ) не равно 100%, то выравнивания (переброса потоков на другие ЦПУ) не происходит Глаза протри и посмотри ещё раз на график. Где там НЕ ПРОИСХОДИТ перебрасывания??? Там совершенно очевидно, что с одного ядра в случае CFS одна и та же нагрузка перебрасывается на другое ядро и обратно.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	75. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 17:31
	по графикам видно только одно: на первом - планировщик даёт потокам поработать (погрузить) свой, перманенто-постоянный проц. на втором - схожесть графиков говорит, что происходит выравнивание нагрузки по процам. а что это значит? (или вообще бред показывает - не могут процы быть равномерно нагружены если нагрузка не стремится к 0% или 100%)
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	69. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 17:11
	в довесок: вот в этом комменте - http://www.opennet.dev/openforum/vsluhforumID3/58585.html#44 есть пруфлинк. если его всё-таки прочитать (можно ещё и глянуть там же исходники), то количество бреда в Ваших коментах (думаю... а может и нет. х/з) уменьшиться.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	70. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 17:15
	>в довесок: вот в этом комменте - http://www.opennet.dev/openforum/vsluhforumID3/58585.html#44 есть пруфлинк. Это только слова, графики на десктопе этого не подтверждают. >если его всё-таки прочитать (можно ещё и глянуть там же исходники), то >количество бреда в Ваших коментах (думаю... а может и нет. х/з) >уменьшиться. Вчера смотрел исходники BSF, Коливас между прочим один из разработчиков CFS судя по комментам, а именно в вопросе интерактивности вносил изменения. Давай показывай пальцем где в исходниках где CFS должен обделывать BSF на дестопе при количестве ядер меньше 8 скажем?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	74. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 17:26
	графики там (Ваши) вообще ничего не подтверждают. общая нагрузка на проц и есть - общая нагрузка на проц. более того, если графики нагрузки на все процы одинаковые (или стремятся к "одинаковости"), то это как раз и доказывает, что потоки перебрасываются и выравнивают нагрузку на обоих (или сколько бы их не было). не говоря уже о дискретности взятия проб для этих графиков. методов сбора (где гарантия, что новый планировщик BSF не искажает данные? ведь судя по графику программы должны работать вдвое быстрее, т.е. визуально должно быть заметно, а этого нет) короче, либо пруфлинк (желательно с анализом кода), либо - в сад (возможно детский).
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	76. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от fidaj (ok) on 08-Сен-09, 17:33
	>ведь судя >по графику программы должны работать вдвое быстрее, т.е. визуально должно быть >заметно, а этого нет) > Для сложения сигналов в шкале 100% - амплитуды сигналов складываются и делятся на количество сигналов...
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	81. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 17:46
	это в теоретической математике :-D а на практике следующие постулаты: 1. единицей выполнения является поток 2. поток может выполнятся в определённый момент только на одном проце 3. когда поток выполняется - нагрузка на проц 100% 4. если пишут, что нагрузка 35% - это значит, что 35% от времени наблюдения проц работал, а 65% - нет.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	83. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от fidaj (ok) on 08-Сен-09, 17:52
	>это в теоретической математике :-D > >а на практике следующие постулаты: >1. единицей выполнения является поток >2. поток может выполнятся в определённый момент только на одном проце >3. когда поток выполняется - нагрузка на проц 100% >4. если пишут, что нагрузка 35% - это значит, что 35% от >времени наблюдения проц работал, а 65% - нет. Не вижу никаких противоречий в этом...
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	88. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 18:09
	кроме одного - нет никакой амплитуды сигналов (цифровая техника, мля. не аналоговая). проц (вернее ядро) в данный момент либо работает, либо нет.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	89. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от fidaj (ok) on 08-Сен-09, 18:17
	>кроме одного - нет никакой амплитуды сигналов (цифровая техника, мля. не аналоговая). > >проц (вернее ядро) в данный момент либо работает, либо нет. Значит вы не имеете ни малейшего понятия об этом: http://ru.wikipedia.org/wiki/Категория:Численные_методы
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	93. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 18:23
	Вы специально переводите разговор на другую тему? (я в курсе численных методов. давайте поговорим всёже о планировщиках)
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	95. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от fidaj (ok) on 08-Сен-09, 18:30
	>Вы специально переводите разговор на другую тему? >(я в курсе численных методов. давайте поговорим всёже о планировщиках) Увы - нет - не перевожу. Эти методы распространяются на обработку практически любых видов и форм сигналов, в том числе и цифровых, к которым и относится циклограмма работы всех без исключения цифровых интегральных схем, к которым CPU к стати тоже относится... Это я к тому, что графики УЖЕ отображают огибающую-результат методов расчета загрузки CPU - вот именно по этому я и не видел никакой разницы и тем более противоречий...
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	97. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 18:43
	>Это я к тому, что графики УЖЕ отображают огибающую-результат методов расчета загрузки CPU а я о чём говорил? вопрос в другом - каким образом по данным графикам оппонент пытался доказать, что CFS перекидывает потоки с одного цпу (естесствено, предполагается из разговора - без системно и без причинно), на другой. а вот усреднённая нагрузка со второго графика как раз может говорить и об этом (но не факт).
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	98. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от fidaj (ok) on 08-Сен-09, 19:02
	>>Это я к тому, что графики УЖЕ отображают огибающую-результат методов расчета загрузки CPU > >а я о чём говорил? > >вопрос в другом - каким образом по данным графикам оппонент пытался доказать, >что CFS перекидывает потоки с одного цпу (естесствено, предполагается из разговора >- без системно и без причинно), на другой. > >а вот усреднённая нагрузка со второго графика как раз может говорить и >об этом (но не факт). http://pobeg1980.livejournal.com/1941.html Поскольку метод отображения/расчетов графиков был один и тот же для разных планировщиков - то данные графики можно считать объективными, и с очевидностью можно сделать вывод о том, что: на верхнем графике (рассматривая степень загрузки ядра как исследуемый процесс) процесс на протяжении 60 сек мигрировал с одного ядра на другое, поскольку уровень одной линии на графике уменьшалься ровно на столько - на сколько увеличивалься уровень другой линии; что нельзя сказать о нижнем графике - с точки зрения методов численного анализа - там (на нижнем...) процессы проистекают практически одинаково - с учетом погрешности метода...
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	100. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 19:57
	а где гарантия, что планировщик не влияет на сбор данных о загруженности? >на верхнем графике (рассматривая степень загрузки ядра как исследуемый процесс) процесс на протяжении 60 сек мигрировал с одного ядра на другое, я в данное время не смотрю фильмы... и всё-же количество процессов (не потоков!!!) $ ps -ef|wc     201    1901   17825 потоков же: $ ps axms|wc     493    5339   59453 о каком из этих процессов Вы говорите? какой из них мигрировал? а CPU всего 2... а переключаться между задачами надо.... а CPU всего 2... а переключаться между задачами надо.... а CPU всего 2... а переключаться между задачами надо.... через сколько времени не будет играть роли на каком проце восстановит работу поток будут? (Вы ведь владеете методами? :-D) >поскольку уровень одной линии на графике уменьшалься ровно на столько - на сколько увеличивалься уровень другой линии; да будет Вам известно, что mplayer (да и флэшь) запускаются в несколько потоков. обычно в столько, сколько есть в системе ядер (если явно не указать. >что нельзя сказать о нижнем графике - с точки зрения методов численного анализа - там (на нижнем...) процессы проистекают практически одинаково - с учетом погрешности метода... что говорит, что контекст выполнения переключается ГОРАЗДО чаще между физическими ядрами. т.е. абсолютно противоположенное, чем то, о чём говорил Дохтор. короче, все эти рассуждения для человека, мало знакомого с деталями....
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	101. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от fidaj (ok) on 08-Сен-09, 20:00
	Я не о том процессе :))) http://ru.wikipedia.org/wiki/Процесс http://ru.wikipedia.org/wiki/Случайный_процесс
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	102. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 20:12
	вот не надо за идиота считать. :-D не при помощи этого была попытка доказать, что якобы согласно графикам CFS перебрасывает нагрузку с проца на проц.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	106. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от fidaj (ok) on 08-Сен-09, 20:41
	>вот не надо за идиота считать. :-D И в мыслях не было... >не при помощи этого была попытка доказать, что якобы согласно графикам CFS >перебрасывает нагрузку с проца на проц. С моей стороны я как раз только при помощи этого и пытался доказать - так как в ядерных тонкостях не спец...
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	110. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 21:49
	ну так поймите следующее: 1. квант премени выполнения конкретной задачи на проце - очень маленькая велична (загрузка проца при этом - 100%). погрешность измерений (в приведённых графиках) с ним и рядом не стояла. 2. график показывает (усреднённо) работу всех потоков в системе. 3. показатель планировщика - работа в граничных условиях ps: о численных медотах - Вы общались с преподавателем информатики (архитектура, асм, с/с++). бывшим правда. Ж-ВВВВВВВВВВВВВВВВВв
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	117. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 22:35
	мне просто интересно общаться с умными (не лесть!!! просто как ещё выразиться)... даже если мнения не совпадают. просто в данном случае Вы не знаете "чистоты" эксперемента - в частности, как Вы отнесётесь к тому, если загрузка ЦПУ будет всегда 100% и при этом количество процессов будет больше (и они будут отзывчевее), чем в системе, где загрузка 30%. а ведь такое было уже. (если вспомнишь сей факт - возьми с полки пирожёк :-D) >И о численных методах у меня был диплом, который успешно защитил! отличная тема. вот только там НИКОГДА не ставят под сомнения истинность полученных данных. >Знали бы вы чуток физику - то поняли бы о чем я тут пытался вам рассказать! физ-мат. отделения физика-информатика. это математикам не фажны способы получения данных и чистота эксперимента. >Честь имею! удачи! :-D
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 22:06
	>1. квант премени выполнения конкретной задачи на проце - очень маленькая велична (загрузка проца при этом - 100%). Хренасе _очень маленькая_, от 1 миллисекунды до 4-х и выше (если не принимать во внимание dinamics trics). В твоей системе по твоим словам более 5000 потоков, которые за 5 секунд могут только получить шанс выполнится и то не факт. >2. график показывает (усреднённо) работу всех потоков в системе. >3. показатель планировщика - работа в граничных условиях Бла-бла-бла... демагогия.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	118. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 22:38
	1 или 4 к 250 - какой процент? и покажите на Вашем графике хотя бы 4. а так же количество процессов (в каждой конкретной точке).
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	129. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 23:45
	не стоит так самокритично..... всё-таки ты о чём то думал, когда сей бред писал. не расстраивайся! :-D на заметку: что именно выполняет ядро? и при каких условиях оно прекращает выполнение текущей задачи и переходит к следующей? зы: задача повышенной сложности: не забываем про кэш (и кода, и данных).
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 20:19
	>я в данное время не смотрю фильмы... и всё-же количество процессов (не потоков!!!) >$ ps -ef|wc >    201    1901   17825 >потоков же: >$ ps axms|wc >    493    5339   59453 Млять, перечитай ещё раз свою книгу грамотей, функция балансировки нагрузки load_balance() у CFS вызывается раз в 200 миллисекунд, ищет очереди в которых потоков на 25% больше чем в текущей и раскидывает по других очередям привязанным к другим ядрам. Именно это и отражено на графике и мои слова про полную миграцию с ядра на ядро раз в 0.5-1 секунду именно это и обозначают. Ядро не может моментально все потоки раскидать, это идёт постепенно.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	104. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 20:32
	во всех перечисленных тобой (и мной) книгах на сколько мне известно нет описания CFS (который, насколько мне известно с 2.6.23) >Млять, перечитай ещё раз свою книгу грамотей, функция балансировки нагрузки load_balance() у CFS вызывается раз в 200 миллисекунд, что говорит о том, что выполняющийся поток перманентно привязан к процу. какова погрешность по оси X в твоих графиках? ну, грамотей, ответь? выходит, что именно в BFS перекидывается нагрузка с проца на проц НАМНОГО чаще.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	105. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 20:40
	>во всех перечисленных тобой (и мной) книгах на сколько мне известно нет описания CFS (который, насколько мне известно с 2.6.23) В твоей книжонке может и нету, а в книге Linux kernel architecture (Wolfgang Mauerer) есть страница 107, глава 2.6.2 "CFS Operations". Так же это есть и в книге Роберта Лава на странице 83, глава "балансировка нагрузки" >что говорит о том, что выполняющийся поток перманентно привязан к процу. Ты уже КНИГИ известных людей оспариваешь.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	107. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 20:56
	Новые данные, сейчас код CFS поковырял, в коде ядра 2.6.30 балансировка происходит раз в 250 миллисекунд при этом ограниченно число потоков (не больше 32) которые подвергаются балансировке т.к. это происходит при отлючённых прерываниях.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	108. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от pavel_simple (ok) on 08-Сен-09, 21:25
	>Новые данные, сейчас код CFS поковырял, в коде ядра 2.6.30 балансировка происходит >раз в 250 миллисекунд при этом ограниченно число потоков (не больше >32) которые подвергаются балансировке т.к. это происходит при отлючённых прерываниях. а давайте всё-же конструктивно, я понимаю что никто не решилси серьёзно потестить, но может..... http://sourceware.org/systemtap/examples/process/chng_cpu.stp может этот вариант всем подойдёт?
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	109. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от pavel_simple (ok) on 08-Сен-09, 21:27
	>[оверквотинг удален] >>раз в 250 миллисекунд при этом ограниченно число потоков (не больше >>32) которые подвергаются балансировке т.к. это происходит при отлючённых прерываниях. > >а давайте всё-же конструктивно, я понимаю что никто не решилси серьёзно потестить, >но может..... > > >http://sourceware.org/systemtap/examples/process/chng_cpu.stp > >может этот вариант всем подойдёт? ну и заодно методика голый init + 2 агрессивных процесса * число ядер?
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	115. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 22:25
	не плохо. действительно, использовать systemtap - это к месту. но боюсь использовать загрузку цп как единственный критерий - не корректно. BFS (как говорят) создана для увеличения отзыва системы (чтобы это не значило). а, согласно графикам топика, по производительности на загрузке в 100% она уже слила. зы: может и займусь (если интересно) написанием рядом скриптов для системтэп. но только в виртуалке (начальные условия одинаковые). вот только смысл?
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	116. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от pavel_simple (ok) on 08-Сен-09, 22:34
	>[оверквотинг удален] >но боюсь использовать загрузку цп как единственный критерий - не корректно. >BFS (как говорят) создана для увеличения отзыва системы (чтобы это не значило). > >а, согласно графикам топика, по производительности на загрузке в 100% она уже >слила. > >зы: >может и займусь (если интересно) написанием рядом скриптов для системтэп. >но только в виртуалке (начальные условия одинаковые). >вот только смысл? смысла по большому счёту никакого нет. 1. Коливас он конечно молодез определённо, но его хаки многим судя по всему не подуше. 2. и самое главное естественно что CFS не перекидывает каждый раз процесс на другой проц -- это явная глапость. 3. а использовать debug / systemtap нужно было раньше - тогда бы не пришлось "спорить о разном" и высказывать недовольство друг-другом. P.S. "А вот и не подерётесь , а я не посмотрю" (C) Народная Мудрось
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	120. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 22:45
	>1. Коливас он конечно молодез определённо, но его хаки многим судя по всему не подуше. я рад что такие люди есть! он - творец. он что сделал..... я уважаю таких людей. >3. а использовать debug / systemtap нужно было раньше - тогда бы не пришлось "спорить о разном" и высказывать недовольство друг-другом а как? опять скажут, что тесты не для десктопа.....
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	124. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 23:02
	>2. и самое главное естественно что CFS не перекидывает каждый раз процесс >на другой проц -- это явная глапость. Глупость и эту глупость сказал ты. Мной было сказано, что CFS производит балансировку раз в 250 миллисекунд и перемещает потоки с ядра на ядро при условии, что есть очередь в которой на 25% и более потоков, причём приоритет отдаётся спящим потокам при перемещении т.к. вероятность hot cache тут наименьшая и при отсутствии таковых перемещает работающие потоки. Смотри kernel/sched.c
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	127. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от pavel_simple (ok) on 08-Сен-09, 23:38
	>>2. и самое главное естественно что CFS не перекидывает каждый раз процесс >>на другой проц -- это явная глапость. > >Глупость и эту глупость сказал ты. >Мной было сказано, что CFS производит балансировку раз в 250 миллисекунд и >перемещает потоки с ядра на ядро при условии, что есть очередь >в которой на 25% и более потоков, причём приоритет отдаётся спящим >потокам при перемещении т.к. вероятность hot cache тут наименьшая и при >отсутствии таковых перемещает работающие потоки. >Смотри kernel/sched.c mistype а вас зацепило.... больше не к чему было ? а теперь смотрим пост  #(58) и делаем выводы. и да -- сказал я "глапость" по ошибке - так ведь мне не сложно в этом признаться. 29 лет? точно?
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	131. "Автор CFS провел исследование производительности планировщик..."	–1 +/–
	Сообщение от Doctor (??) on 08-Сен-09, 23:53
	>и да -- сказал я "глапость" по ошибке - так ведь мне >не сложно в этом признаться. А ты дебил будешь отрицать, что у CFS есть балансировщик нагрузки который гоняет раз в 250 миллисекунд потоки?
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	135. "Автор CFS провел исследование производительности планировщик..."	–1 +/–
	Сообщение от pavel_simple (ok) on 09-Сен-09, 00:02
	>>и да -- сказал я "глапость" по ошибке - так ведь мне >>не сложно в этом признаться. > >А ты дебил будешь отрицать, что у CFS есть балансировщик нагрузки который >гоняет раз в 250 миллисекунд потоки? аааа.... раз пошла такая, то я себе тоже разок позволю... а ты животное отчего решил, что если твой проф уровень позволяет тебе мести помойным ебальником на всех вокруг, при этом нести откровенную ахинею то тебя блядина кто-то должен уважать или выслушивать несостоятельные сказки. - иди дрочни на kernel/sched.c и ложись уже спать - завтра модераторы тут всё почистят, включая твой пост #58 - из-за которого мы наблюдаем это падение нравов, "профессионал" блин -- схавал бы давно и никто бы не заметил. ...ух... прошу прощение уважаемой публики.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	138. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 09-Сен-09, 00:08
	блин. ну а как ещё общаться то? кто скажет про тот же kernel/sched.c (вон из тебя скоко тянуть пришлось... пока не обозвали) сообщество, мля...
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	136. "Автор CFS провел исследование производительности планировщик..."	–1 +/–
	Сообщение от vitek (??) on 09-Сен-09, 00:03
	окуеть!!! а ты, умный чел, будешь отрицать, что в BFS есть планировщик?
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	128. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 23:38
	тобой тут (http://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi?az=sh...) было сказано: >CFS постоянно с ядра на ядро перебрасывает. BSF же такого НЕ делает. а вот это: >Мной было сказано, что CFS производит балансировку раз в 250 миллисекунд и перемещает потоки с ядра на ядро при условии, что есть очередь в которой на 25% и более потоков, причём приоритет отдаётся спящим потокам при перемещении т.к. вероятность hot cache тут наименьшая и при отсутствии таковых перемещает работающие потоки. оговорка по Фрэйду. :-D самое время прокричать CFS сакс, BFS -форевер.... и вспомнить твой график, как доказательство!!! :-DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	133. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 09-Сен-09, 00:00
	ну кто мог догадаться, что ты имел в иду ровно противоположенное? :-D (если и так... мог бы поправиться сразу.... не так уж много людей, задумывающихся об этом... могли бы и сотрудничать...) >... который с ядра на ядро перебрасывает? все перебрасывают. вопрос в деталях (для меня критерий уже есть - проц не может жрать 100 пока другой пустует - остальное туфта)
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	137. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 09-Сен-09, 00:05
	>ну кто мог догадаться, что ты имел в иду ровно противоположенное? :-D Что противоположное т.е. балансировщик перестал постоянно гонять с ядра на ядро с квантом времени или перемещает только раз и всё?! >(если и так... мог бы поправиться сразу.... не так уж много людей, >задумывающихся об этом... могли бы и сотрудничать...) Мне сотрудничать ничего не мешает и сейчас, в этом вопросе политически гибок. предлагайте.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	139. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 09-Сен-09, 00:25
	>Мне сотрудничать ничего не мешает и сейчас, в этом вопросе политически гибок. предлагайте. ну ежели так.... имеем в CFS/BFS -  разница в различной нагрузке на процы (о периодичности -и графиках пока не вспоминаем) - это как раз и есть показатель, что планировщик до последнего (пока есть хоть малейшая возможность съэкономить на повторном выполнении) держит проц за одним потоком (не процессом), но... если этот поток из процесса "переднего плана" (Вы там фильмы смотрели вроде?): - рано или поздно, но этот проц оказывается "более" загруженным, чем второй. - картина повторяется со вторым процом - (в кавычках - все mplayer'ы идут в несколько потоков и равны количеству процов.... но это всё равно происходит....) хм... о сотрудничестве.... например могли бы на этом примере разработать набор тестов (и для десктопов в том числе! системтэп - отличное предлежение!) - разработчики шедулеров бы на них ориентировались..... все в плюсе. опеннет захостил бы такие скрипты?...
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	140. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor1 on 09-Сен-09, 00:27
	Тестирование мне не интересно.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	141. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor1 on 09-Сен-09, 00:28
	>Тестирование мне не интересно. Мне разработка интересна, за деньги
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	143. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 09-Сен-09, 00:34
	тебе интересны просто деньги. зы: лично мне и лично ты - не нужен. вопрос к модераторам - набор таких скриптов нужен?
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	144. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от pavel_simple (ok) on 09-Сен-09, 00:36
	>тебе интересны просто деньги. > >зы: >лично мне и лично ты - не нужен. >вопрос к модераторам - набор таких скриптов нужен? я много плюсую за набор тестов.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	147. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 09-Сен-09, 00:57
	может подумаем вместе? интересно жеж.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	148. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 09-Сен-09, 01:00
	я б и сам... токо мне и так всё ясно. а послушаешь некоторых - думаешь, да пошли вы все. а так - было бы интересно. этож почти регресс-тест.... очень увеличило б скорость отладки.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	149. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от pavel_simple (ok) on 09-Сен-09, 01:14
	>я б и сам... токо мне и так всё ясно. >а послушаешь некоторых - думаешь, да пошли вы все. > >а так - было бы интересно. >этож почти регресс-тест.... очень увеличило б скорость отладки. скрипты погонять на тачке? - да отчего-же нет? всегда за. на регресс-тест похоже мало, но хоть посмотрю как там этот bfs робит. завтра ядра подготовлю, только интересно чем интерактивность мерять, voip под нагрузкой? мыша+x window? - так что эти самые тесты ещё очень долго придумывать - речь то ведь о десктопе идёт, смотрим кино под нагрузкой lzma? мысли?
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	150. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 09-Сен-09, 01:38
	ок. я тоже (но в витруалке - vkm + vmx) ps: >на регресс-тест похоже мало, но хоть посмотрю как там этот bfs робит. по началу - да. а так - новые ядра вполне можно тестить. (а из-за чего - отдельная песТНя) >тмысли? олько интересно чем интерактивность мерять, voip под нагрузкой? мыша+x window? вот и мне интересно - критериев то нет. на ум приходит только rt. >мысли? ну... скрипты и есть скрипты... будем пополнять/изменять_пополнять и т.д. на любой вкус. вышло ядро (или рк) - протестили... кто-то сказал, что не так... спросим, а как - вот новый скрипт. ну.. как-то так я думаю (опеннет - новый фороникс!!! :-D)
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	151. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 09-Сен-09, 01:43
	s/vkm/kvm
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	84. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 17:53
	>это в теоретической математике :-D > >а на практике следующие постулаты: >1. единицей выполнения является поток >2. поток может выполнятся в определённый момент только на одном проце >3. когда поток выполняется - нагрузка на проц 100% при текущей частоте, ядро может понижать частоту проца. >4. если пишут, что нагрузка 35% - это значит, что 35% от >времени наблюдения проц работал, а 65% - нет.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	86. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 18:08
	>при текущей частоте, ядро может понижать частоту проца. тафтология. правильно так - при определённой НАГРУЗКЕ (методы подсчёта могут быть разными) ядро (или так - через системные вызовы ядра) может понижать частоту проца.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	78. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 17:43
	>графики там (Ваши) вообще ничего не подтверждают. общая нагрузка на проц и >есть - общая нагрузка на проц. Получается с твоих слов, постоянно гонять ядра на ядро это никак в плане производительности не сказывается, кэш здесь не участвует и не тормозит код из-за отсутствия значений в кэше... Ну-ну. >более того, если графики нагрузки на все процы одинаковые (или стремятся к >"одинаковости"), то это как раз и доказывает, что потоки перебрасываются и >выравнивают нагрузку на обоих (или сколько бы их не было). не >говоря уже о дискретности взятия проб для этих графиков. методов сбора Это говорит, что потоки у BFS на пихаются на одно ядро, чтобы второе было свободно для потоков kernel space. Это говорит о том, что BFS исполняет потоки на обоих ядрах одновременно, что НЕ ЗНАЧИТ что он их перебрасывает с ядра на ядро. CFS же пытается исполнят потоки user space на одном ядре оставляя второе ядро для kernel space и периодически перемещает потоки с ядра на ядро видимо для избежания перегрева одного ядра, возможно ещё из-за каких-то причин. CFS это больше планировщик для много процессорных маших и серверов. >(где гарантия, что новый планировщик BSF не искажает данные? ведь судя >по графику программы должны работать вдвое быстрее, т.е. визуально должно быть >заметно, а этого нет) Это вообще трындец, ещё раз глаза протри, где там в два раза превосходство на графике?! Там на несколько десятков процентов превосходство. Что кстати немного заметно. >короче, либо пруфлинк (желательно с анализом кода), либо - в сад (возможно >детский). Короче сливаешь, графики я привёл. Ты вякнул про код, так вот анализ кода должен быть с твоей стороны потому, как размер кода CFS раз в 5-10 больше размера кода BFS. Пытаться найти в коде BFS то чего нет это глупо. Давай анализ кода CFS на предмет того почему он должен быть быстрее BFS.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	85. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 18:02
	>Получается с твоих слов, постоянно гонять ядра на ядро это никак в плане производительности не сказывается, не понял, что хотел сказать. кто куда и кого гоняет - не понятно... я не ясно написал, что из твоих графиков это не следует? и пруфлинка, подтверждающего это, от тебя не видел. > кэш здесь не участвует и не тормозит код из-за отсутствия значений в кэше... Ну-ну. почему? кэш тормозит. но как это происходит? для этого и есть планировщики и такие понятия, как контекст процесса, аппаратный контекст, сегмент состояния задачи и т.д. а вообще, переключение происходит только в одном месте ядра - функция shedule() - рекомендую. >Это вообще трындец, ещё раз глаза протри... плохо мы ещё воспитываем нашу молодёж... >Короче сливаешь, графики я привёл. Ты вякнул про код, так вот анализ кода должен быть с твоей стороны ... ну-ну. я (в отличие от тебя) анализ (или объяснение) твоих графиков привёл. а ты даже их не объяснил. (это - "график прыгает, как кардиограмма, азначит потоки перекидываются" - бред сивой кобылы) короче. слил ты всё, господин студент из меда.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	87. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 18:08
	Дядя, про устройство ядра я прочёл три книги две на русском Лав, Бовет и Чезати, и книгу Wolfgang Mauerer на английском почти прочёл потому не нужно мне объяснять где, что переключается. Если для тебя не очевидно, что в случае CFS на графике одна и та же нагрузка перемещается с ядра на ядро считаю диспут с тобой законченным, ты не хочешь видеть очевидного. Имеющий глаза увидит.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	90. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от pavel_simple (ok) on 08-Сен-09, 18:18
	>Дядя, про устройство ядра я прочёл три книги две на русском Лав, >Бовет и Чезати, и книгу Wolfgang Mauerer на английском почти прочёл >потому не нужно мне объяснять где, что переключается. > >Если для тебя не очевидно, что в случае CFS на графике одна >и та же нагрузка перемещается с ядра на ядро считаю диспут >с тобой законченным, ты не хочешь видеть очевидного. Имеющий глаза увидит. > вот все так много книжек прочитали, а взять о поставить kernel debuger + да счётчики на breakpoint'ы а потом посчитать не всилах -- легче языком трепаться. 3 книжки говоришь ? отлично -- я думаю все будут рады увидеть конкретные данные а не болтовню типа "да у меня всё равно длиннее"
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	91. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 18:21
	>вот все так много книжек прочитали, а взять о поставить kernel debuger >+ да счётчики на breakpoint'ы а потом посчитать не всилах -- >легче языком трепаться. > >3 книжки говоришь ? отлично -- я думаю все будут рады увидеть >конкретные данные а не болтовню типа "да у меня всё равно >длиннее" $500 на WM кошелёк и договорились. От бесплатной работы даже кони дохнут.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	152. "Автор CFS провел исследование производительности планировщик..."	–1 +/–
	Сообщение от vitek (??) on 09-Сен-09, 02:24
	>$500 на WM кошелёк и договорились. От бесплатной работы даже кони дохнут. за ночь или за час? (интересно же сколько "кони" стоят...)
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	92. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 18:22
	Тётя, я их тоже прочёл. + Клаудия Зальзберг Родригес, Гордон Фишерб и Стивен Смольски (Азбука ядра) но видимо (в твоём случае) - это ничего не значит. Если ты не можешь объяснить свои же графики, также не можешь указать на кусок кода в ядре, где по твоим словам каждые 0,5c CFS переключает контекст выполнения с одного физического ядра на другой (чтобы жизнь мёдом не казалась, не иначе), а не в зависимости от нагрузки, то как говорится - слив засчитан.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	94. "Автор CFS провел исследование производительности планировщик..."	+1 +/–
	Сообщение от Doctor (??) on 08-Сен-09, 18:25
	>Тётя За это можно и по лицу получить в реале. >Если ты не можешь объяснить свои же графики, также не можешь указать >на кусок кода в ядре, где по твоим словам каждые 0,5c >CFS переключает контекст выполнения с одного физического ядра на другой (чтобы >жизнь мёдом не казалась, не иначе), а не в зависимости от >нагрузки, то как говорится - слив засчитан. Ещё раз, для тех кто в танке искать в CFS я ничего тебе не обязан, размер кода сильно больше чем у BFS, сам ищи.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	96. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 18:35
	а ты думал только тебе можно применять унижительные обращения? такшта, шёл бы ты со своими претензиями лесом. >Ещё раз, для тех кто в танке искать в CFS я ничего тебе не обязан, размер кода сильно больше чем у BFS, сам ищи. т.е. твои слова: > CFS постоянно с ядра на ядро перебрасывает. BSF же такого НЕ делает. просто голый трёп. ну я уже писал - слив засчитан.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	68. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от fidaj (ok) on 08-Сен-09, 17:10
	>С какого хера мой пост потёрли, аргументов не осталось кроме цензуры? > >Вот скриншот, ещё будешь утверждать, что CFS с ядра на ядро не >гоняет? >http://pobeg1980.livejournal.com/1941.html Для четкости - говорю о 10-й секунде графиков(правильней конечно все просуммировать/интегрировать на участке в 60 сек)... Суммарная нагрузка системы на нижнем графике ~37.5%, а на верхнем ~43.75% - это говорит что система на нижнем графике при тех же задачах менее нагружена? Я прав?
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	71. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 17:17
	>Суммарная нагрузка системы на нижнем графике ~37.5%, а на верхнем ~43.75% - >это говорит что система на нижнем графике при тех же задачах >менее нагружена? >Я прав? Полагаю дело обстоит так.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	72. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от fidaj (ok) on 08-Сен-09, 17:21
	>>Суммарная нагрузка системы на нижнем графике ~37.5%, а на верхнем ~43.75% - >>это говорит что система на нижнем графике при тех же задачах >>менее нагружена? >>Я прав? > >Полагаю дело обстоит так. Применим ли BFS на RT ядрах?
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	73. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 17:24
	>Применим ли BFS на RT ядрах? Незнаю, код RT патча не смотрел. Нужно смотреть не пересекаются ли RT и BSF патчи. По идее теоретически это может вместе работать.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	77. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от vitek (??) on 08-Сен-09, 17:43
	начнём с того, что этот код написан Инго Молнаром.... и завязан на планировщик. >По идее теоретически это может вместе работать. смотря что.... ряд патчей, которые обработку прерываний просто запихнули в отдельные потоки (а не в очередь)... но опять же, как они будут обработаны. планировщик тут - важная вещь.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	80. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 17:46
	>начнём с того, что этот код написан Инго Молнаром.... и завязан на >планировщик. >смотря что.... ряд патчей, которые обработку прерываний просто запихнули в отдельные потоки >(а не в очередь)... но опять же, как они будут обработаны. >планировщик тут - важная вещь. Начнём с того, что после вчерашнего просмотра кода BFS сложилось впечатление, что Коливас выкинул внутренности CFS заменив своим кодом сохранив API.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	79. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от fidaj (ok) on 08-Сен-09, 17:43
	>>Применим ли BFS на RT ядрах? > >Незнаю, код RT патча не смотрел. Нужно смотреть не пересекаются ли RT >и BSF патчи. По идее теоретически это может вместе работать. Во многих конфигах ядер параметр CONFIG_NR_CPUS=64 - имеет ли смысл - для сборки с патчами BFS уменьшить этот параметр до значений, в которых BFS работает более эффективно например до 8?
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	82. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Doctor (??) on 08-Сен-09, 17:47
	>Во многих конфигах ядер параметр CONFIG_NR_CPUS=64 - имеет ли смысл - для >сборки с патчами BFS уменьшить этот параметр до значений, в которых >BFS работает более эффективно например до 8? Ненужно, всё что нужно в патче устанавливается. Там это откомментированно
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

18. "Автор CFS провел исследование производительности планировщик..."	+2 +/–
Сообщение от whip on 07-Сен-09, 11:47
а чего спорить-то, добавляли-бы все планировщики и давали возможность пользователю легко их переключать, пусть сам под свои задачи выбирает. в винде и то что-то подобное есть.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "Автор CFS провел исследование производительности планировщик..."	+1 +/–
	Сообщение от vitek (??) on 07-Сен-09, 11:58
	а вот это правильно. и шоб через граб можно было выбирать какой надо.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	27. "Автор CFS провел исследование производительности планировщик..."	+1 +/–
	Сообщение от Doctor (??) on 07-Сен-09, 12:36
	Верно! И чтоб ещё можно было выбирать частоту таймера шедулера(250, 300, 1000).
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	47. "Автор CFS провел исследование производительности..."	+/–
	Сообщение от anonymous (??) on 07-Сен-09, 18:08
	>Верно! И чтоб ещё можно было выбирать частоту таймера шедулера(250, 300, 1000). и ведь что смешно-то? что уже можно. зачем будущее время для того, что давно уже сделано — не понятно.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	55. "Автор CFS провел исследование производительности..."	+/–
	Сообщение от ТТТ on 08-Сен-09, 09:29
	И это можно где-то переключать на ходу? хотя сомневаюсь что из переключений можно извлечь что-то полезное...
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

20. "Автор CFS провел исследование производительности планировщик"	+5 +/–
Сообщение от Akademic (??) on 07-Сен-09, 11:57
Да... Инго взял такие типичные для декстоп систем задачи как сборка ядра и postgresql. Я прям каждый день на своём нетбуке ядра собираю, да хостинг кручу.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	23. "Автор CFS провел исследование производительности планировщик"	–4 +/–
	Сообщение от vitek (??) on 07-Сен-09, 12:05
	и что Вы предлагаете? выкинуть CFS? ps: у меня на ноуте кластер из виртуалок с субд... у каждого своё понятие о десктопе. но если ещё и сервера начнут тормозить, то... вендекапец не за горами. pps: а ведь он ещё и тюнится.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	30. "Автор CFS провел исследование производительности планировщик"	+2 +/–
	Сообщение от User294 (ok) on 07-Сен-09, 13:22
	>  и что Вы предлагаете? выкинуть CFS? А нафиг выкидывать то? > у меня на ноуте кластер из виртуалок с субд... ИМХО, мсье знает толк в извращениях :D > а ведь он ещё и тюнится. Угу, представь себе картину маслом - чайниковатые юзеры тюнят шедулер, ага. По-моему, они тогда BFS'ом назовут какой-то другой шедулер. P.S. я так и не понял почему в вашем понимании десктоп по дефолту должен работать хуже чем мог бы и только с напильником и почему BFS не имеет права на жизнь как нечто опциональное, а там пусть майнтайнеры в меру своих понятий о применении их ОС думают. Не, не вариант?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	34. "Автор CFS провел исследование производительности планировщик"	–4 +/–
	Сообщение от vitek (??) on 07-Сен-09, 14:20
	>ИМХО, мсье знает толк в извращениях :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? (хотя я не против, чтобы можно было выбирать. ситуация в данном случае не такая, как с Рейзером)
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	51. "Автор CFS провел исследование производительности планировщик"	+1 +/–
	Сообщение от User294 (ok) on 07-Сен-09, 21:05
	>>ИМХО, мсье знает толк в извращениях :D Ну да, а первый вопрос тактично не замечен :).Я честно говоря не вижу разумных причин выбросить один планировщик лишь потому что в состав ядра включен второй и мелкий. >тесты, экспиреенс,... денюжка в дом. а тут сразу и виртуализация, и кластеризация, >и айскази (и пр. ай....) И все это на ноутбуке :)))).Нет, я был прав в своих выводах, I'm sorry. Ну ладно я там еще на 4-ядерном десктопе с 8 гиг оперативы испытываю понятные желания попользоваться благами цивилизации и машиной с ресурсами приличного сервера как-то похитрее >пусть тюнят дистростроители - generic, server, rt, etc. Ага, вместо того чтобы сделать нормальное решение от правильных парней, надо нагородить кучу велосипедов :).В итоге получится куча багов и прочая. Мне кажется что пихнуть в ядро bfs не настолько большое зло (вплане распухона кода и прочая) как потенциальный глюкодром от такого местечкового велосипедострительства. >и будет востребовано, то rt будет нормой для любого ядра. ну >и напуркуа тогда BFS? (хотя я не против, чтобы можно было >выбирать. Вот я и не понимаю - почему бы не воткнуть bfs до кучи, он что, такой здоровый и требует много изменений? Наверное в ряде применений как то всякие мелкие эмбеддед железки без всяких монстрильных постгресов, NUMA и прочая, но зато с дохлым процом в три комариные силы простой шедулер с минимальным оверхедом и обеспечивающий хорошую отзывчивость системы смотрелся бы правильным выбором.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	53. "Автор CFS провел исследование производительности планировщик"	+/–
	Сообщение от vitek (??) on 08-Сен-09, 00:03
	>Ну да, а первый вопрос тактично не замечен :). конечно тактично. :-D глупо отвечать на вопрос, который был дан как "ответ" на первоначальный. >Ага, вместо того чтобы сделать нормальное решение от правильных парней, надо нагородить кучу велосипедов :). кто такие? и о какой куче идёт речь? насколько я понял - Вы за то, чтобы в эту кучку ещё пару планировщиков добавить? или нет? Вы уж определитесь - должна эта куча расти или нет.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	32. "Автор CFS провел исследование производительности планировщик"	+2 +/–
	Сообщение от _Vitaly_ (ok) on 07-Сен-09, 13:33
	Зачем выкидывать? Просто для начала определиться с постановкой задачи. А то будет как в тестах фороникса - ежа с ужом, бобра с козлом.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	36. "Автор CFS провел исследование производительности планировщик"	–1 +/–
	Сообщение от vitek (??) on 07-Сен-09, 14:24
	вот чуть выше (34 коммент) описал задачу. CFS и реалтайм смогут вполне конкурировать с BFS. и не только. макос вот тоже рт. и тоже уже никс.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	38. "Автор CFS провел исследование производительности планировщик"	+2 +/–
	Сообщение от Doctor (??) on 07-Сен-09, 14:51
	Бред, по производительности CFS и риалтайм вместе будут уступать BSF. В плане интерактивности различий не будет. Сейчас в ядре идёт активная работа по замене BKL (big kernel lock) на mutex и его фундамент futex. После зхавершенияэтой работы rt нужен будет только в сугубо специфических случаях, как обработка видео и т.п.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	40. "Автор CFS провел исследование производительности планировщик"	–1 +/–
	Сообщение от vitek (??) on 07-Сен-09, 15:17
	оба положения - не факт. а BKL ну вообще не в той опере где рт. в любом случае - это определённая концепция... которой у BSF нет (хорошо если ещё чего не поломает... особенно того, что до этого отлично работало) зы: впрочем ниже я писал, что было бы не плохо, если бы можно было выбирать при загрузке/компиляции ядра.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	42. "Автор CFS провел исследование производительности планировщик"	+1 +/–
	Сообщение от Doctor (??) on 07-Сен-09, 15:30
	>оба положения - не факт. а BKL ну вообще не в той опере где рт Речь не о принципах обеспечения rt, а о сравнении CFS и BSF и цели написания BSF. Коливас пишет, что его достали замирания курсора мыши и невозможность на 100% всю мощь многоядерных процессоров. на графиках Коливаса это прекрасно видно, CFS только начиная с большого количества потоков начинает распределять ресурсы ядер полноценно. Так вот замирания курсора мыши следствие BKL. РТ же не может дать той производительности, что BSF так по понятным причинам будут накладные расходы. >в любом случае - это определённая концепция... которой у BSF нет Которая BSF не нужна, цели написания BSF описаны выше. Нужен RT ставь rt ядро/патч. >(хорошо если ещё чего не поломает... особенно того, что до этого отлично работало) У меня всё пашет, как часы на BSF.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	44. "Автор CFS провел исследование производительности планировщик"	–2 +/–
	Сообщение от vitek (??) on 07-Сен-09, 16:21
	а я вот разницы не заметил. что так, что так - визуально одно и тоже - может квалификация не та, а может лень меряться, искать линейки-методики :-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-х вариантов я выберу тот, что без приключений на пятую точку. хоть и посмотрю на альтернативы (по возможности)
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	60. "Автор CFS провел исследование производительности планировщик"	+/–
	Сообщение от vitek (??) on 08-Сен-09, 14:53
	и ничего в ответ... всё равно поясню :-D: 1. Con Kolivas разработал свой планировщик BFS для лучшей отзывчивости системы (а не для 100% мощи, как говорит Дохтур выше). и это понятно - лично на моём ноуте проц(ы) 95% времени висит на частоте 800MHz. 2. для 100% мощи Ingo Molnar как раз разработал планировщик CFS см. цитату чуть выше и графики от него самого в топике - подтверждение, которое и Con Kolivas вроде не опровергает. 3. рт также способствует увеличению отзывчивости. при объединение его с CFS. (ах да! увеличение нагрузки на проц! интересно, а как быстро я замечу разницу, когда мой десктоп на 800Mhz будет проводить не 95%, а 93% времени?)
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

29. "Автор CFS провел исследование производительности планировщик..."	+3 +/–
Сообщение от User294 (ok) on 07-Сен-09, 13:15
> Результаты исследования представлены на четырех графиках: kbuild > (производительность сборки ядра Linux),  (hackbench - производительность > обмена сообщениями), oltp (postgresql + sysbench), pipe (скорость > обмена данными через pipe). Оригинально. Они там что, шлангами прикидываются? CK написал планировщик для десктопа. И более идиотских бенчмарков для ДЕСКТОПА чем перечисленное я затрудняюсь себе представить. Интересно, а что мешает включить этот планировщик как опциональный и не пользоваться им для упомянутых задач?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	33. "Автор CFS провел исследование производительности планировщик..."	+3 +/–
	Сообщение от Аноним (??) on 07-Сен-09, 13:36
	> что мешает включить этот планировщик как опциональный и не пользоваться им для упомянутых задач? Из серии: Что мешает переходу на GPLv3? Политика. Кон - он как бы анестезиолог, а не программист. Каково линусу и монлару осознавать, что один анастезиолог делает для десктопа в linux больше, чем два программиста? Кроме того есть ещё принцип "жопе слова не давали". Если Кон обретёт признание, у него не будет надобности проталкивать свой код, и освободится время на то чтобы толкать свой взгляд на вещи. А это нонконформизм, который линусу и его фанатикам не нужны.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	49. "Автор CFS провел исследование производительности планировщик..."	+2 +/–
	Сообщение от User294 (ok) on 07-Сен-09, 20:45
	>Политика. Кон - он как бы анестезиолог, а не программист. Простите, не-программисты не могут написать такой шедулер, по определению. Является ли этот род деятельности full time или нет - не так уж и важно, человек программист если он умеет программировать. А программирует ли он час в день, 2 часа или 8 - это уже его дело. Давайте еще откажем в звании музыканта всем тем кто не играет музыку с утра до вечера? oO >Каково линусу и монлару осознавать, что один анастезиолог делает для десктопа в linux >больше, чем два программиста? В глобальном плане у них может быть своя логика - как то данный шедулер сливает в других задачах (что не есть гуд).А тянуть добавочный код в ядро наверняка резонно не хочется(там и так шыта навалом).Выбросить совсем одно в пользу другого опять же не вариант судя по бенчам и тому что автор сам не скрывает что его шедулер полезен далеко не везде. До того как говорить политика надо рассмотреть логику всех сторон. Разве нет? >А это нонконформизм, который линусу и его фанатикам не нужны. Вообще, команда работающая над проектом все-таки должна действовать согласовано и желательно без выяснений у кого длиннее и грызни и пикировок, иначе ничего хорошего не выйдет. Басню лебедь, рак и щука знаете? Кто-то впишется, кто-то нет. Такова жизнь. И делать трагедию или клоунаду из очевидных (но видимо не всем?) вещей как-то инфантильно. Но вот Молнар искренне удивил своей аргументацией. То что CK его нелестно заткнул - логичное следствие. Итого я вижу простую как топор ситуацию - Молнар протупил (в лучшем случае), на что CK резко ответил. При том резкость до некоторой степени понятна. До некоторой, да. Но вообще, если бы люди были сдержаннее, их сосущетвование было бы намного приятнее.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	57. "Автор CFS провел исследование производительности планировщик..."	–2 +/–
	Сообщение от ТТТ on 08-Сен-09, 09:54
	> человек программист если он умеет программировать смешно звучит... как будто программирование это религия и если ты умеешь молиться компьютерному богу значит ты программист :-) но вообще с автором согласен умеешь программировать значит программист, а есть такие которые и учились этому и программируют, но лучше бы они этого не делали
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	153. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Аноним (??) on 09-Сен-09, 11:10
	> Является ли этот род деятельности full time или нет - не так уж и важно Очень важно. Линус по сути чиновник. Если чиновнику обосновать что ты можешь делать его работу лучше его подчинённых, он рад не будет. > тянуть добавочный код в ядро наверняка резонно не хочется(там и так шыта навалом) 1. Если там и так навалом шита, будет ли хуже от ещё небольшой капельки? 2. Их никто не просил никуда ничего добавлять. Им спецом отдельно сказали что их шедулер не касается и поддерживаться будет без них. > Вообще, команда работающая над проектом все-таки должна действовать согласовано и желательно без выяснений у кого длиннее и грызни и пикировок, иначе ничего хорошего не выйдет. Да я уж со счёта сбился сколько народу с линусом разосралось и бросило поддерживать код. Хорошая у него комманда, только код виндой и рефакторингом уже попахивает. > если бы люди были сдержаннее, их сосущетвование было бы намного приятнее Проблема далеко не в сдержанности, а в неадекватном положении линуса и монлара (см. басню "кукушка и петух"). И Кон это прекрасно понимает, так что смысла как-то сдерживаться нет.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	155. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от User294 (ok) on 11-Сен-09, 21:27
	>Очень важно. Линус по сути чиновник. Если чиновнику обосновать что ты можешь >делать его работу лучше его подчинённых, он рад не будет. Он не чиновник. Он - project manager огромного проекта. Это нереально геморная должность с огромной ответственностью.Потому что ряд промахов - и бац - вы уже в шкуре капитана Титаника, наблюдающего как недавно еще вполне живой проект идет ко дну и пускает пузыри. Ну а хороший капитан - прибывет в порт назначения без приключений. Торвальдс за столько лет доказал что он - хороший капитан. И - да, иногда таким людям приходится принимать не самые простые решения и сталкиваться с не особо приятными вещами. И в конце концов - это капитанское дело - какие решения принять и кого набрать в матросы. >1. Если там и так навалом шита, будет ли хуже от ещё >небольшой капельки? Будет, разумеется. Один подвалит, другой подвалит... как известно, из капель собираются реки. Так что в итоге получится обычная такая глюкавая монстрила. >2. Их никто не просил никуда ничего добавлять. Им спецом отдельно сказали >что их шедулер не касается и поддерживаться будет без них. Но ведь сказали же. А значит они в своем праве высказаться. Другое дело что Молнар использовал эту возможность весьма странно. >Да я уж со счёта сбился сколько народу с линусом разосралось и >бросило поддерживать код. И что? В целом - орава народа пашет, команда ядерщиков - есть. А на вообще всех 1 фиг не угодишь и некоторые будут друг с другом сраться. И как бы если вы считаете что сможете лучше - можете попробовать, как бы законом не запрещено. Проблема только в том что у 99.9(9)% людей потянуть проект такого уровня кишка тонка. Ругать можно, а толку? Есть железная уверенность что [некто] поставленный в те же условия выступит лучше Торвальдса? У меня на этот счет большие сомнения. Во всяком случае что-то я других столь же успешных руководителей проектов не вижу на каждом углу. Покажите их - тогда поверю. > Хорошая у него комманда, только код виндой и рефакторингом уже попахивает. Странное у вас чувство обоняния. И опять же - никто никому ничего не должен. Торвальдс делает так как ему удобно. Если вам не нравится - пытаетесь делать лучше, валите на что-то иное или там как вам удобно. А Торвальдс делает свое дело. Как умеет. Кому по вкусу - пользуется. Кому не по вкусу - не пользуется. Вроде просто все. Если утверждается что можно и лучше - так докажите. А то пока что доказательств не вижу чего-то. Как максимум можно попробовать указать на промахи. Тактично по возможности. А вот с нахрапом требовать их устранения - не выйдет. А кто вы, чтобы пытаться другим приказывать что им *требуется* делать? Можете *посоветовать*, желательно аргументированно. Не более. >Проблема далеко не в сдержанности, а в неадекватном положении линуса и монлара Неадекватном?! Торвальдс создал этот проект и развил его до состояния в котором оно сейчас. А тут приходите вы и заявляете что у него неадекватное положение? Интересное кино. Да, не без помощи других. Но не будь Торвальдса - все могло бы быть совсем иначе. А кому не нравится положение и состояние дел как бы в своем праве форкнуть например, или действовать как им там удобно. Ну там свою команду создать, написать что-то с нуля и лучше, использовать что-то иное и еще два зиллиона вариантов. Какие проблемы то? >смысла как-то сдерживаться нет. А это зависит от того какие цели и какие результаты хочется получить. Кстати да, если люди сработались - совершенно нормальная ситуация что один человек пытается прикрыть коллегу при нападках на него. Моя точка зрения - не совсем правы обе стороны. Если CK не хотел пикировок, стоило бы быть сдержаннее и вести себя иначе. А Молнар просто толи протормозил, толи воспринял это как булыжник в свой огород. В общем хрень какая-то.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	37. "Автор CFS провел исследование производительности планировщик..."	+2 +/–
	Сообщение от IGX on 07-Сен-09, 14:25
	Похоже, Инго в танке или броневике.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	39. "Автор CFS провел исследование производительности планировщик..."	+4 +/–
	Сообщение от Аноним (??) on 07-Сен-09, 15:10
	>Похоже, Инго в танке или броневике. Если быть точнее, Он на броневике. :)
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

52. "Автор CFS провел исследование производительности планировщик..."	–1 +/–
Сообщение от Аноним (??) on 07-Сен-09, 21:08
Мёд, срач двух луноходов это просто мёд :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

56. "Автор CFS провел исследование производительности планировщик..."	+/–
Сообщение от ТТТ on 08-Сен-09, 09:48
Тесты Инго меня абсолютно убедили только в одно, что надо подаваться в разработчики ядра если у них у всех такие десктопы как в его тестах: 2-х процессорные четрыехядерники с гиперсредингом :-) (наверное не зря и Колин туда рветься :-) ) а по существу:   даже на этих 2-х процессорных как двигалась мышка и можно ли было просматривать фильму во время таких тестов?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	154. "Автор CFS провел исследование производительности планировщик..."	+/–
	Сообщение от Аноним (??) on 10-Сен-09, 10:58
	> даже на этих 2-х процессорных как двигалась мышка и можно ли было просматривать фильму во время таких тестов? Я удивлю некоторых и скажу: Можно! Но! У меня ноут, на ноуте два ядра. Каждое ядро по умолчанию работает с пониженным энергопотреблением. В условиях CFS задача скачет с одного ядра на другое и linux-у приходится постоянно повышать частоту на одном из ядер (на другом автоматом понижать). Такой перескок с повышением частоты длиться от половины секунды. Так что: приходится в ручную задавать тактовую частоту максимальной при просмотре фильмов, при запуске флеша или для любой другой ресурсоёмкой задачи. Это автоматом означает п-ц заряду в батарейке. При ситуации на рынке когда от 40% покупателей компьютеров покупают именно ноуты это ОЧЕНЬ критичный фактор. И на него линусу и монлару наплевать. Из-за гонора или из-за того что им приплачивают микросовтовцы - х.з., но неадекват на лицо.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема