В списке рассылки разработчиков ядра Linux представлен (https://lkml.org/lkml/2012/12/15/96) новый планировщик задач, основанный на коде планировщика BFS (http://ck.kolivas.org/patches/bfs/) (Brain Fuck Scheduler), но отличающийся возможностью использования нескольких очередей выполнения (runqueue). Патчи с реализацией нового планировщика подготовлены для ядра 3.6.2.
Планировщик BFS ориентирован на обеспечение оптимальной отзывчивости, интерактивности и пропускной способности при решении типичных пользовательских задач на обычных компьютерах. Основная реализация BFS, поддерживаемая Коном Коливасом (Con Kolivas), манипулирует процессами в рамках одной глобальной очереди задач для всех CPU, что позволяет свести к минимуму паразитную нагрузку от работы планировщика, но приводит к проблемам с масштабируемостью на многоядерных системах (BFS эффективен на системах, имеющих менее 16 ядер). Маттиас Кёлер (Matthias Kohler), автор нового варианта BFS, переработал архитектуру планировщика для обеспечения его оптимальной работы на многоядерных системах.
Суть внесённых изменений сводится к добавлению нескольких очередей выполнения, каждая из которых привязывается к одному или нескольким ядрам CPU и отвечает за планирование выполнения процессов только для указанных ядер CPU. Таким образом, удаётся обойти проблемы с масштабируемостью BFS на системах с большим числом процессорных ядер.
Ценой наличия нескольких очередей является необходимость поддержания дополнительных механизмов для балансировки нагрузки между очередями, что снижает эффективность.
В качестве выхода предоставлена возможность гибкой настройки числа очередей, что позволяет выбрать оптимальное число очередей для имеющегося числа процессорных ядер или особенностей рабочей нагрузки на систему. Например, возможно использование одной глобальной очереди как в классическом BFS (для максимальной отзывчивости), использование отдельной очереди для каждого ядра CPU (для максимальной масштабируемости) или привязка одной очереди к паре ядер CPU.
По заявлению автора проекта разработка пока находится на стадии начального прототипа и ещё требует проведения доработки и оптимизации алгоритма балансировки нагрузки. В будущем в проект планируется добавить некоторые возможности из используемого по умолчанию в ядре Linux планировщика CFS, в основном связанные с управлением пропускной способностью и обеспечением минимальных задержек. При этом, разработка сохранит минималистичный характер и как BFS будет содержать гораздо меньше строк кода, чем в CFS.URL: https://lkml.org/lkml/2012/12/15/96
Новость: https://www.opennet.ru/opennews/art.shtml?num=35618
Для нуба может кто объяснить, рендеринг(большая часть алгоритмов хорошо паралелится) на процессоре(ах) ускорится или нет ?
В теории - да
нет
Расскажи это GPU, битком набитому SIMD-образными числокрушилками.
1. Тема по CPU шыдулер
2. Тред про рендеринг.
3. SIMD и GPU, гы...[сообщение отредактировано модератором]
> Для нуба может кто объяснить, рендеринг(большая часть алгоритмов хорошо паралелится) на
> процессоре(ах) ускорится или нет ?нет, конечно.
Рендер требует очень много floating-point операций. Видеокарта это умеет делать значительно лучше процессора — она специально на это заточена. Так что нет, привлечение процессора только замедлит работу. Разве что как вспомогательное звено если недогружен.
Аха только вот почему то все программы рендеринга делают свое дело на CPU
Blender c Cycles render использует GPU например, причем на глаз раз в 5 быстрее рендерить на gpu (core 2 duo 3гг, gtx 570 ti)
> Аха только вот почему то все программы рендеринга делают свое дело на CPUЭто вы просто с ручника еще не снялись. Вот и ...
Не должно, это просто увеличивает скорость переключения между потоками, скорость самих потоков не изменяется
неправда, скорость самих потоков может замедлится. Любой планировщик с хорошей отзивчивостью для десктопного испольщования гробит производительность отдельно взятого потока/процесса.
а может и ускориться, если попадут в кеш. Зависит от конкретной реализации. Так что тут только кофейная гуща и шарик )
Более быстрое переключение между потооками кэш, по идее, наоборот больше портить бдует
> Более быстрое переключение между потооками кэш, по идее, наоборот больше портить бдуетПо какой такой идее?
>> Более быстрое переключение между потооками кэш, по идее, наоборот больше портить бдует
> По какой такой идее?Ну как же - чем дольше активен один поток - тем дольше нужен уму его кэш. Запустили другой - у него инструкции/данные другие - грузи заново...
>>> Более быстрое переключение между потооками кэш, по идее, наоборот больше портить бдует
>> По какой такой идее?
> Ну как же - чем дольше активен один поток - тем
> дольше нужен уму его кэш. Запустили другой - у него инструкции/данные
> другие - грузи заново...По частоте попадания в кэш, можно судить об не оптимальности алгоритма.
Если порой CACHE_HIT много, надо смотреть, чё там творится.
вообще нерелевантный показатель для 'что-то там не так'
> вообще нерелевантный показатель для 'что-то там не так'if (a > 10 )
x + a;
else if (a > 200 )
x + a + 2;
else if (a > 50 )
x + a + 3;
else if (a > 100)
x + a + 4;
else if (a > 1000 )
x + a + 5;Нормальный код? Например в ядре линя такая фигня в mmconfig.c (как-то так).
>[оверквотинг удален]
> x + a;
> else if (a > 200 )
> x + a + 2;
> else if (a > 50 )
> x + a + 3;
> else if (a > 100)
> x + a + 4;
> else if (a > 1000 )
> x + a + 5;
> Нормальный код? Например в ядре линя такая фигня в mmconfig.c (как-то так).Нет такого файла в ядре - наверное ты сам его и дописал?
>[оверквотинг удален]
> Нет такого файла в ядре - наверное ты сам его и дописал?А то, сижу пешу
2.6 - 2.6.23
arch/i386/pci/mmconfig.c
arch/i386/pci/mmconfig-shared.c
arch/x86_64/pci/mmconfig.c2.6.24 - 3.7
arch/x86/pci/mmconfig_64.c
arch/x86/pci/mmconfig_32.c
arch/x86/pci/mmconfig-shared.c
> 2.6.24 - 3.7
> arch/x86/pci/mmconfig_64.c
> arch/x86/pci/mmconfig_32.c
> arch/x86/pci/mmconfig-shared.cЭти файлы есть. Но представленного тобой кода в них нет. Значит этот быдлокод таки ты сам и дописываешь?
> Значит этот быдлокод таки ты сам и дописываешь?нужно - найдешь, ориентир MMCONFIG
>> Значит этот быдлокод таки ты сам и дописываешь?
> нужно - найдешь, ориентир MMCONFIGЯ по всему дереву исходников грепал - нет в ядре такого кода
>>> Значит этот быдлокод таки ты сам и дописываешь?
>> нужно - найдешь, ориентир MMCONFIG
> Я по всему дереву исходников грепал - нет в ядре такого кодаКонечно нет. А кто говорил, что этот код из ядра?
>>>> Значит этот быдлокод таки ты сам и дописываешь?
>>> нужно - найдешь, ориентир MMCONFIG
>> Я по всему дереву исходников грепал - нет в ядре такого кода
> Конечно нет. А кто говорил, что этот код из ядра?удивительные иногда диалоги на опеннете...
"Сообщение от pavlinux (ok) on 21-Дек-12, 16:50
> вообще нерелевантный показатель для 'что-то там не так'
if (a > 10 )
x + a;
else if (a > 200 )
x + a + 2;
else if (a > 50 )
x + a + 3;
else if (a > 100)
x + a + 4;
else if (a > 1000 )
x + a + 5;Нормальный код? Например в ядре линя такая фигня в mmconfig.c (как-то так)."
>>>> Значит этот быдлокод таки ты сам и дописываешь?
>>> нужно - найдешь, ориентир MMCONFIG
>> Я по всему дереву исходников грепал - нет в ядре такого кода
> Конечно нет. А кто говорил, что этот код из ядра?Ты
ключевое слово *может*. Т.е. в жизни разное бывает. Когда вторые корки появились с большим кешем, наблюдал 10-кратный рост на одной задачке CGI мультитредовой (частота и пр. кроме кеша были одинаковые).
а задачка тоже в обоих случаях была мультитредовой?
ну это совсем навряд ли. Чем мельче гранулярность (т.е. low latency планеровщик), тем выше конкруренция за единицу кэша в единицу времени (~ лезет больше потоков со своими локально уникальными данными). Фактически эффективной работе кэша это тоже вредит.
То есть они прибили весь смысл single run-queue, на котором BFS строилась. Ну что, молодцы.
Читай внимательнее. Для желающих оставить одну очередь на все CPU эта возможность осталась.
Интересно было бы увидеть сравнительные тесты
на каком же десктопе/лаптопе более 16 ядер? а как же каждой задаче - свой инструмент?
> на каком же десктопе/лаптопе более 16 ядер? а как же каждой задаче
> - свой инструмент?Может это как бы намек что не для серверов этот планировщик.
подождите пару лет - и в телефоне не будет хватать 16 ядер :)
> подождите пару лет - и в телефоне не будет хватать 16 ядер
> :)через пару лет "это" уже не будет называться телефоном...
16 ядер должно хватить каждому!
хэх, копирайтер, не вспомнят тебя через 10 лет.
Письмо в будущее себе пошли, потом поржеш через 10 лет.
> поржешВас граммар-наци расстреляют явно быстрее чем через 10 лет, если продолжите в таком же духе.
2023 на дворе, 32 потока в домашних процессорах
> на каком же десктопе/лаптопе более 16 ядер?Наверное потому что десктоп у которого ядер меньше чем у МОБИЛЬНИКА будет смотреться издевательски. И кстати 8-ядерники для мобил и планшетов уже анонсированы.
ждём выхода Brain Fuck Linux - дистрибутива где этот планировщик используется по умолчанию
PCLinuxOS
Установите Ubuntu
> Установите UbuntuЕсли дистрибутив трахает юзеру мозг - это еще не значит, что там используется BFS.
Что можно сказать.. Все равно не примут этот шедулер в mainstream - RH в лице своего девелопера Ingo - в очередной раз найдет кучу причин что бы отказать.
> Что можно сказать.. Все равно не примут этот шедулер в mainstream -
> RH в лице своего девелопера Ingo - в очередной раз найдет кучу причин что бы отказать.Ох, запилите уже свою операционку с шахматами и поэтессами и покажите этому гадкому линуксу как надо работать.
>> Что можно сказать.. Все равно не примут этот шедулер в mainstream -
>> RH в лице своего девелопера Ingo - в очередной раз найдет кучу причин что бы отказать.
> Ох, запилите уже свою операционку с шахматами и поэтессами и покажите этому
> гадкому линуксу как надо работать.Да что вы так кипятитесь.. Линукс уже давно свою копеечку в RH получает - где он один из главных акционеров.. Так что работать против своего кошелька не будет..
> Да что вы так кипятитесь.. Линукс уже давно свою копеечку в RH
> получает - где он один из главных акционеров..Завидовать нехорошо.
Продолжайте чистить сортиры, авось к пенсии тоже на пару акций накопите :)
> Что можно сказать.. Все равно не примут этот шедулер в mainstream - RH в лице своего девелопера Ingo - в очередной раз найдет кучу причин что бы отказать.Напоминает ситуацию с секс-меньшинствами и их дискриминацией. "Если какой-то гoвнокод не принимают в ядро - значит, это дискриминация по признаку авторства. Надо срочно принять и извиниться!"
К счастю, ядром, в отличие от некоторых государств, управляют отнюдь не долбанутые толерасты.
"Brain Fuck Scheduler"
Вот почему его в основную ветку не взяли :) Несмотря на то, что отец ядра любит комбинацию из среднего пальца крутить.
> "Brain Fuck Scheduler"
> Вот почему его в основную ветку не взяли :) Несмотря на то,
> что отец ядра любит комбинацию из среднего пальца крутить.Не хочу разбивать ваши воздушные замки, но не взяли просто потому, что гoвнокод. А не из-за названия.
Этого доктора уже вроде посылали, он обиделся и вот опять лезет.
> Этого доктора уже вроде посылали, он обиделся и вот опять лезет.перечитай - это теперь уже другой лезет "дохтур"
не все "дохтуры" одинаково полезны...
> Этого доктора уже вроде посылали, он обиделся и вот опять лезет.А доктор кстати довольно приличный програмер. Он например написал свой майнер биткоинов. Кстати, один из лучших получился.
Что, кстати, намекает на уровень профессиональный уровень "профессиональных" программистов.
Никто его никуда не посылал.
BTF, в общем, хорошая штука, но актуальна только для ПК и прочих персональных устройств. На настоящих компьютерах от него, скорее всего, вреда будет больше, чем пользы. Поддерживать два планировщика нынешняя линусовская команда не осилит, а "персональные" рынки с низкой маржой ей не интересны. В то же время, ядреные команды "Андроида" и прочих производных разработок, ориентированных на персональные устройства, почему-то не заинтересовались.
> Никто его никуда не посылал.
> BTF, в общем, хорошая штука, но актуальна только для ПК и прочих
> персональных устройств. На настоящих компьютерах от него, скорее всего, вреда будет
> больше, чем пользы. Поддерживать два планировщика нынешняя линусовская команда не осилит,
> а "персональные" рынки с низкой маржой ей не интересны. В то
> же время, ядреные команды "Андроида" и прочих производных разработок, ориентированных
> на персональные устройства, почему-то не заинтересовались.Это понятно - что абсолютно универсальных вещей в природе не бывает...
Терзает вопрос - ну почему каждый раз изобретают велосипеды?
Есть уже кучи алгоритмов планирования зарекомендовавших себя и показывающих неплохие результаты (говорю об интерактивности) например планировщик в XNU http://www.opensource.apple.com/source/xnu/xnu-2050.9.2/osfm.../ или в Haiku http://cgit.haiku-os.org/haiku/tree/src/system/kernel/scheduler , полно и других (я говорю о тех у которых доступны исходники)...
Зачем такие потуги?
Или монолитность и модульность ядер уже настолько закостенела и взаимно проросла в разные подсистемы ядра что теперь простым способом нельзя отделить одно от другого?
Вон в Haiku, опять-таки например, планировщик меняется почти как модуль, можно вообще скрестить два планировщика и настроить условия передачи обработки запросов на тот планировщик что нужно в данный момент и система будет вести себя адекватно при разных условиях использования и при этом оставаться интерактивной, и прекрасно масштабироваться...Что на этот счет?
> Это понятно - что абсолютно универсальных вещей в природе не бывает...
> Терзает вопрос - ну почему каждый раз изобретают велосипеды?
> Есть уже кучи алгоритмов планирования зарекомендовавших себя и показывающих неплохие результаты
> (говорю об интерактивности) например планировщик в XNU http://www.opensource.apple.com/source/xnu/xnu-2050.9.2/osfm.../Ну это же фирма зла - как вы можете предлагать использовать что-то Apple? от этого у RMS произойдет разрыв сердца..
> как вы можете предлагать использовать что-то Apple? от этого у RMS произойдет разрыв сердца..Apple Public Source License FSF одобрена и является копилефтом.
>Зачем такие потуги?На месте чтобы не стоять, всё правильно делают...
>>Зачем такие потуги?
> На месте чтобы не стоять, всё правильно делают...Двигаться - это не всегда развиваться...
Кстати, у планировщика XNU, хорошо ведущего себя на ПК, при типичной "серверной" нагрузке проблемы того же рода, что и у BFS.Кроме того, микроядерность как таковая на x86 и производных, мягко говоря, неоднозначно сказывается на отзывчивости. XNU это большая удача.
> Кстати, у планировщика XNU, хорошо ведущего себя на ПК, при типичной "серверной"
> нагрузке проблемы того же рода, что и у BFS.хм - поподробнее пожалуйста...
> Кроме того, микроядерность как таковая на x86 и производных, мягко говоря, неоднозначно
> сказывается на отзывчивости. XNU это большая удача.ну на сколько я знаю - там все реализовано через планирование нитями, впрочем, как и у планировщика Haiku...
> Никто его никуда не посылал.Да ну? а фраза линукса - что есть только один шедулер и другой нам не нужен?
> BTF, в общем, хорошая штука, но актуальна только для ПК и прочих персональных устройств.
Ну да. коих процентов 80 у использующих. Ну да.. зачем этот рынок линуксу? лучше иметь свой 1% красноглазых и кичится этим..
> переработал архитектуру планировщика для обеспечения его оптимальной работы на многоядерных системах.Вот оно Линус-style. Я может чего не понимаю, но ОТКУДА на десктопах больше 16-ти ядер возьмется!? Ставлю 5$ что этот патч в офф ядро возьмут.
значит придется ставить от коливаса До чего не дотронутся шаловливые ручонки улучшателей становится всегда хуже, а поддержка over стопицот процев как то совершенно не упала