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

Автор CFS провел исследование производительности планировщик..., opennews (?), 07-Сен-09, (0) [смотреть все] 4096 ядерные компы такие 4096 компы Кон с самого начала заявлял что делает плани, DFX (?), 08:40 , 07-Сен-09, (1) +5 Инго очень старался быть вежливым, молодец А вот ответ Кона граничит с хамством , Просто Лось. (?), 08:41 , 07-Сен-09, (2) –2 // 1 вынести выговор с записью в личное дело 2 премию за планировщик не выплачива, victor (??), 08:54 , 07-Сен-09, (5) +6 Ну, дык, Торвальдс это тоже оценил , empty (?), 10:30 , 07-Сен-09, (12) +2 Автор BFS провел исследование производительности планировщика задач СFS И выясн, Аноним (-), 16:18 , 07-Сен-09, (43) +2 CK какой-то грубый стал или мне показалось 2009 9 7 Ingo Molnar mi elte hu, birdie (?), 08:43 , 07-Сен-09, (3) +1 // Показалось Кон предположил несколько пунктов 1 Инго невнимательно прочитал FAQ , Аноним (-), 17:02 , 07-Сен-09, (45) +2 По-моему, втереть про левые тесты которые не очень то относятся к ДЕСКТОПАМ когд, User294 (ok), 19:56 , 07-Сен-09, (48) +1 Кон Коливас создал BFS не для производительности А для лучшей интерактивности , iZEN (ok), 08:43 , 07-Сен-09, (4) +5 какой толк от этих графиков на десктопе лучше бы Кон сделал репозитарии для деб, mma (?), 08:56 , 07-Сен-09, (6) –5 // Нахрена программеру, ядерному хакеру, заниматься сборкой ядра для твоего Дебиана, Аноним (-), 21:42 , 09-Мрт-14, (156) Коливас ответил грубо, но по делу Тем более, что у Инги радушие лицемерное Впро, morten (?), 09:00 , 07-Сен-09, (7) +1 холивары на уровне разработчиков цирк, J10 (?), 09:57 , 07-Сен-09, (8) // это называется конкуренция а цирк это лучше у внедренцев-консультантов поспра, vitek (??), 10:10 , 07-Сен-09, (9) +1 BFS слишком сырой пока, и я лично уже это заметил на практике CFS вполне нормал, poige (ok), 10:39 , 07-Сен-09, (13) –1 // Открою небольшую тайну - там на linux-rt тоже те же планировщики, что и не у -, fidaj (ok), 11:39 , 07-Сен-09, (16) +2 // Вы хоть его правильно напишите для начала - CFSа CFQ - это I O scheduler - http , vitek (??), 11:56 , 07-Сен-09, (19) –1 // gt оверквотинг удален ой - вот блин - промахнулся не туда и не о том , fidaj (ok), 12:06 , 07-Сен-09, (24) ио-шедулер - вещь интересная не скажу, что мне реализация сильно нравиться, но , vitek (??), 12:24 , 07-Сен-09, (25) Перепутать планировщики CFQ и CFS - это эпично , User294 (ok), 13:27 , 07-Сен-09, (31) +1 я лично поставил BFS на gentoo-sources-2 6 30-r6, kde стартанул и все повисло, н, vl (??), 11:45 , 07-Сен-09, (17) // не хорошо но к шедулерам это отношения не имеет Линус тоже за словом в карман н, vitek (??), 12:00 , 07-Сен-09, (22) +2 Поставил BSF на ядро 2 6 30 2 в ubuntu 9 10 beta 5 Всё работает идеально, по ощ, Doctor (??), 12:34 , 07-Сен-09, (26) +3 // Да, есть вопрос Вот CFS специально пытается грузить сначала одно ядро по полной, Doctor (??), 12:52 , 07-Сен-09, (28) +1   // на intel atom а также на power pc если загрузить только одно ядро получается нем, аноним (?), 20:59 , 07-Сен-09, (50) +1   Вообще то это не совсем так Теория говорит всего лишь что не стоит перебрасыват, ТТТ (?), 09:26 , 08-Сен-09, (54)   Т е CFS для intel Atom, Athlon и прочих процов с малым кэшем заведомо будет бол, Doctor (??), 11:51 , 08-Сен-09, (58)   Вы сами себе противоречите - то он у Вас только один проц по максимуму грузит, т, vitek (??), 14:39 , 08-Сен-09, (59)   Млять, специально для тех кто в танке ещё раз CFS пытается исполнять на одном яд, Doctor (??), 15:22 , 08-Сен-09, (61)   специально для тех, кто в окопе 1 видимо именно поэтому этот планировщик и обго, vitek (??), 16:02 , 08-Сен-09, (62)   С какого хера мой пост потёрли, аргументов не осталось кроме цензуры Вот скриншо, Doctor (??), 16:58 , 08-Сен-09, (64)   гы-ы-ы-ы первое что доказывает только одно - на каждом проце при CFS работает СВ, vitek (??), 17:04 , 08-Сен-09, (66)   Глаза протри и посмотри ещё раз на график Где там НЕ ПРОИСХОДИТ перебрасывания , Doctor (??), 17:09 , 08-Сен-09, (67)   по графикам видно только одно на первом - планировщик даёт потокам поработать п, vitek (??), 17:31 , 08-Сен-09, (75)   в довесок вот в этом комменте - http www opennet ru openforum vsluhforumID3 5, vitek (??), 17:11 , 08-Сен-09, (69)   Это только слова, графики на десктопе этого не подтверждают Вчера смотрел исходн, Doctor (??), 17:15 , 08-Сен-09, (70)   графики там Ваши вообще ничего не подтверждают общая нагрузка на проц и есть , vitek (??), 17:26 , 08-Сен-09, (74)   Для сложения сигналов в шкале 100 - амплитуды сигналов складываются и делятся н, fidaj (ok), 17:33 , 08-Сен-09, (76)   это в теоретической математике -Dа на практике следующие постулаты 1 единицей , vitek (??), 17:46 , 08-Сен-09, (81)   Не вижу никаких противоречий в этом , fidaj (ok), 17:52 , 08-Сен-09, (83)   кроме одного - нет никакой амплитуды сигналов цифровая техника, мля не аналого, vitek (??), 18:09 , 08-Сен-09, (88)   Значит вы не имеете ни малейшего понятия об этом http ru wikipedia org wiki К, fidaj (ok), 18:17 , 08-Сен-09, (89)   Вы специально переводите разговор на другую тему я в курсе численных методов д, vitek (??), 18:23 , 08-Сен-09, (93)   Увы - нет - не перевожу Эти методы распространяются на обработку практически люб, fidaj (ok), 18:30 , 08-Сен-09, (95)   а я о чём говорил вопрос в другом - каким образом по данным графикам оппонент пы, vitek (??), 18:43 , 08-Сен-09, (97)   http pobeg1980 livejournal com 1941 htmlПоскольку метод отображения расчетов г, fidaj (ok), 19:02 , 08-Сен-09, (98)   а где гарантия, что планировщик не влияет на сбор данных о загруженности я в дан, vitek (??), 19:57 , 08-Сен-09, (100)   Я не о том процессе http ru wikipedia org wiki Процессhttp ru wikipedia , fidaj (ok), 20:00 , 08-Сен-09, (101)   вот не надо за идиота считать -Dне при помощи этого была попытка доказать, что, vitek (??), 20:12 , 08-Сен-09, (102)   И в мыслях не было С моей стороны я как раз только при помощи этого и пытался , fidaj (ok), 20:41 , 08-Сен-09, (106)   ну так поймите следующее 1 квант премени выполнения конкретной задачи на проце , vitek (??), 21:49 , 08-Сен-09, (110)   мне просто интересно общаться с умными не лесть просто как ещё выразиться , vitek (??), 22:35 , 08-Сен-09, (117)   Хренасе _очень маленькая_, от 1 миллисекунды до 4-х и выше если не принимать во, Doctor (??), 22:06 , 08-Сен-09, (113)   1 или 4 к 250 - какой процент и покажите на Вашем графике хотя бы 4 а так же кол, vitek (??), 22:38 , 08-Сен-09, (118)   не стоит так самокритично всё-таки ты о чём то думал, когда сей бред писал , vitek (??), 23:45 , 08-Сен-09, (129)   Млять, перечитай ещё раз свою книгу грамотей, функция балансировки нагрузки load, Doctor (??), 20:19 , 08-Сен-09, (103)   во всех перечисленных тобой и мной книгах на сколько мне известно нет описания, vitek (??), 20:32 , 08-Сен-09, (104)   В твоей книжонке может и нету, а в книге Linux kernel architecture Wolfgang Mau, Doctor (??), 20:40 , 08-Сен-09, (105)   Новые данные, сейчас код CFS поковырял, в коде ядра 2 6 30 балансировка происход, Doctor (??), 20:56 , 08-Сен-09, (107)   а давайте всё-же конструктивно, я понимаю что никто не решилси серьёзно потестит, pavel_simple (ok), 21:25 , 08-Сен-09, (108)   gt оверквотинг удален ну и заодно методикаголый init 2 агрессивных процесса , pavel_simple (ok), 21:27 , 08-Сен-09, (109)   не плохо действительно, использовать systemtap - это к месту но боюсь использова, vitek (??), 22:25 , 08-Сен-09, (115)   gt оверквотинг удален смысла по большому счёту никакого нет 1 Коливас он коне, pavel_simple (ok), 22:34 , 08-Сен-09, (116)   я рад что такие люди есть он - творец он что сделал я уважаю таких людей а, vitek (??), 22:45 , 08-Сен-09, (120)   Глупость и эту глупость сказал ты Мной было сказано, что CFS производит баланси, Doctor (??), 23:02 , 08-Сен-09, (124)   mistype а вас зацепило больше не к чему было а теперь смотрим пост 58 и, pavel_simple (ok), 23:38 , 08-Сен-09, (127)   А ты дебил будешь отрицать, что у CFS есть балансировщик нагрузки который гоняет, Doctor (??), 23:53 , 08-Сен-09, (131) –1   аааа раз пошла такая, то я себе тоже разок позволю а ты животное отчего ре, pavel_simple (ok), 00:02 , 09-Сен-09, (135) –1   блин ну а как ещё общаться то кто скажет про тот же kernel sched c вон из тебя , vitek (??), 00:08 , 09-Сен-09, (138)   окуеть а ты, умный чел, будешь отрицать, что в BFS есть планировщик , vitek (??), 00:03 , 09-Сен-09, (136) –1   тобой тут http www opennet ru cgi-bin openforum vsluhboard cgi az show_thread, vitek (??), 23:38 , 08-Сен-09, (128)   ну кто мог догадаться, что ты имел в иду ровно противоположенное -D если и так, vitek (??), 00:00 , 09-Сен-09, (133)   Что противоположное т е балансировщик перестал постоянно гонять с ядра на ядро , Doctor (??), 00:05 , 09-Сен-09, (137)   ну ежели так имеем в CFS BFS - разница в различной нагрузке на процы о пер, vitek (??), 00:25 , 09-Сен-09, (139)   Тестирование мне не интересно , Doctor1 (?), 00:27 , 09-Сен-09, (140)   Мне разработка интересна, за деньги, Doctor1 (?), 00:28 , 09-Сен-09, (141)   тебе интересны просто деньги зы лично мне и лично ты - не нужен вопрос к модерат, vitek (??), 00:34 , 09-Сен-09, (143)   я много плюсую за набор тестов , pavel_simple (ok), 00:36 , 09-Сен-09, (144)   может подумаем вместе интересно жеж , vitek (??), 00:57 , 09-Сен-09, (147)   я б и сам токо мне и так всё ясно а послушаешь некоторых - думаешь, да пошли , vitek (??), 01:00 , 09-Сен-09, (148)   скрипты погонять на тачке - да отчего-же нет всегда за на регресс-тест похоже , pavel_simple (ok), 01:14 , 09-Сен-09, (149)   ок я тоже но в витруалке - vkm vmx ps по началу - да а так - новые ядра вполн, vitek (??), 01:38 , 09-Сен-09, (150)   s vkm kvm, vitek (??), 01:43 , 09-Сен-09, (151)   при текущей частоте, ядро может понижать частоту проца , Doctor (??), 17:53 , 08-Сен-09, (84)   тафтология правильно так - при определённой НАГРУЗКЕ методы подсчёта могут быть, vitek (??), 18:08 , 08-Сен-09, (86)   Получается с твоих слов, постоянно гонять ядра на ядро это никак в плане произво, Doctor (??), 17:43 , 08-Сен-09, (78)   не понял, что хотел сказать кто куда и кого гоняет - не понятно я не ясно нап, vitek (??), 18:02 , 08-Сен-09, (85)   Дядя, про устройство ядра я прочёл три книги две на русском Лав, Бовет и Чезати,, Doctor (??), 18:08 , 08-Сен-09, (87)   вот все так много книжек прочитали, а взять о поставить kernel debuger да счёт, pavel_simple (ok), 18:18 , 08-Сен-09, (90)   500 на WM кошелёк и договорились От бесплатной работы даже кони дохнут , Doctor (??), 18:21 , 08-Сен-09, (91)   за ночь или за час интересно же сколько кони стоят , vitek (??), 02:24 , 09-Сен-09, (152) –1   Тётя, я их тоже прочёл Клаудия Зальзберг Родригес, Гордон Фишерб и Стивен Смо, vitek (??), 18:22 , 08-Сен-09, (92)   За это можно и по лицу получить в реале Ещё раз, для тех кто в танке искать в CF, Doctor (??), 18:25 , 08-Сен-09, (94) +1   а ты думал только тебе можно применять унижительные обращения такшта, шёл бы ты , vitek (??), 18:35 , 08-Сен-09, (96)   Для четкости - говорю о 10-й секунде графиков правильней конечно все просуммиров, fidaj (ok), 17:10 , 08-Сен-09, (68)   Полагаю дело обстоит так , Doctor (??), 17:17 , 08-Сен-09, (71)   Применим ли BFS на RT ядрах , fidaj (ok), 17:21 , 08-Сен-09, (72)   Незнаю, код RT патча не смотрел Нужно смотреть не пересекаются ли RT и BSF патч, Doctor (??), 17:24 , 08-Сен-09, (73)   начнём с того, что этот код написан Инго Молнаром и завязан на планировщик с, vitek (??), 17:43 , 08-Сен-09, (77)   Начнём с того, что после вчерашнего просмотра кода BFS сложилось впечатление, чт, Doctor (??), 17:46 , 08-Сен-09, (80)   Во многих конфигах ядер параметр CONFIG_NR_CPUS 64 - имеет ли смысл - для сборки, fidaj (ok), 17:43 , 08-Сен-09, (79)   Ненужно, всё что нужно в патче устанавливается Там это откомментированно, Doctor (??), 17:47 , 08-Сен-09, (82)   а чего спорить-то, добавляли-бы все планировщики и давали возможность пользовате, whip (?), 11:47 , 07-Сен-09, (18) +2 // а вот это правильно и шоб через граб можно было выбирать какой надо , vitek (??), 11:58 , 07-Сен-09, (21) +1 // Верно И чтоб ещё можно было выбирать частоту таймера шедулера 250, 300, 1000 , Doctor (??), 12:36 , 07-Сен-09, (27) +1 // и ведь что смешно-то что уже можно зачем будущее время для того, что давно уже, anonymous (??), 18:08 , 07-Сен-09, (47) И это можно где-то переключать на ходу хотя сомневаюсь что из переключений можно, ТТТ (?), 09:29 , 08-Сен-09, (55) Да Инго взял такие типичные для декстоп систем задачи как сборка ядра и postg, Akademic (??), 11:57 , 07-Сен-09, (20) +5 // и что Вы предлагаете выкинуть CFS ps у меня на ноуте кластер из виртуалок с суб, vitek (??), 12:05 , 07-Сен-09, (23) –4 // А нафиг выкидывать то ИМХО, мсье знает толк в извращениях DУгу, представь себе, User294 (ok), 13:22 , 07-Сен-09, (30) +2 // тесты, экспиреенс, денюжка в дом а тут сразу и виртуализация, и кластеризаци, vitek (??), 14:20 , 07-Сен-09, (34) –3 Ну да, а первый вопрос тактично не замечен Я честно говоря не вижу разумных п, User294 (ok), 21:05 , 07-Сен-09, (51) +1 конечно тактично -Dглупо отвечать на вопрос, который был дан как ответ на пе, vitek (??), 00:03 , 08-Сен-09, (53) Зачем выкидывать Просто для начала определиться с постановкой задачи А то буде, _Vitaly_ (ok), 13:33 , 07-Сен-09, (32) +2 // вот чуть выше 34 коммент описал задачу CFS и реалтайм смогут вполне конкуриров, vitek (??), 14:24 , 07-Сен-09, (36) –1 Бред, по производительности CFS и риалтайм вместе будут уступать BSF В плане ин, Doctor (??), 14:51 , 07-Сен-09, (38) +2 оба положения - не факт а BKL ну вообще не в той опере где рт в любом случае - , vitek (??), 15:17 , 07-Сен-09, (40) –1 Речь не о принципах обеспечения rt, а о сравнении CFS и BSF и цели написания BSF, Doctor (??), 15:30 , 07-Сен-09, (42) +1 а я вот разницы не заметил что так, что так - визуально одно и тоже - может ква, vitek (??), 16:21 , 07-Сен-09, (44) –2 и ничего в ответ всё равно поясню -D 1 Con Kolivas разработал свой планиров, vitek (??), 14:53 , 08-Сен-09, (60) Оригинально Они там что, шлангами прикидываются CK написал планировщик для дес, User294 (ok), 13:15 , 07-Сен-09, (29) +3 // Из серии Что мешает переходу на GPLv3 Политика Кон - он как бы анестезиолог, а, Аноним (-), 13:36 , 07-Сен-09, (33) +3 // Простите, не-программисты не могут написать такой шедулер, по определению Являе, User294 (ok), 20:45 , 07-Сен-09, (49) +2 // смешно звучит как будто программирование это религия и если ты умеешь молитьс, ТТТ (?), 09:54 , 08-Сен-09, (57) –2 Очень важно Линус по сути чиновник Если чиновнику обосновать что ты можешь дел, Аноним (-), 11:10 , 09-Сен-09, (153) Он не чиновник Он - project manager огромного проекта Это нереально геморная д, User294 (ok), 21:27 , 11-Сен-09, (155) Похоже, Инго в танке или броневике , IGX (?), 14:25 , 07-Сен-09, (37) +2 // Если быть точнее, Он на броневике , Аноним (-), 15:10 , 07-Сен-09, (39) +4 Мёд, срач двух луноходов это просто мёд , Аноним (-), 21:08 , 07-Сен-09, (52) –1 Тесты Инго меня абсолютно убедили только в одно, что надо подаваться в разработч, ТТТ (?), 09:48 , 08-Сен-09, (56) // Я удивлю некоторых и скажу Можно Но У меня ноут, на ноуте два ядра Каждое ядро, Аноним (-), 10:58 , 10-Сен-09, (154) 1,2,3,4,6,7,8,13,17,18,20,29,52,56

Сообщения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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