Всего сообщений: 8
16 и 19 августа состоялись выпуски 4.0 и 4.0.1 многопоточной консольной утилиты поиска файлов bfs (Breadth-First Search, поиск в ширину), написанной на языке C и распространяемой по лицензии BSD.
( читать дальше... )
>>> Подробности
Появился новый планировщик задач, основанный на коде BFS (Brain Fuck Scheduler), но с возможностью использования нескольких очередей выполнения.
BFS сам по себе использует только одну очередь выполнения для всех CPU. Это позволяет избежать накладных расходов на балансировку нагрузки, но не очень хорошо масштабируется.
Какие преимущества у нового планировщика по сравнению с другими планировщиками?
Какие у него недостатки по сравнению с другими планировщиками?
>>> Подробности
После небольшой задержки, связанной с доработкой планировщика ввода-вывода BFQ, вышел патчсет pf-kernel для Linux v3.3.
Патчсет содержит:
Помимо этого, в выпуске произошли такие изменения:
>>> Официальный сайт
С небольшой задержкой, связанной с отсутствием необходимых патчей, вышла первая версия патчсета pf-kernel для свежего ядра Linux v3.1.
В этой версии:
Также открыт канал на Twitter, в котором, по возможности, будут публиковаться новости, связанные с разработкой pf-kernel.
Напоминаю, что этот патч используется на свой страх и риск. TuxOnIce и патч для уменьшения энергопотребления лично мной не были протестированы. Жду отзывов.
Также напоминаю, что патч применяется к чистому ядру 3.1 без стабилизационных патчей.
Официальный сайт (доступен и в сети IPv6)
>>> Скачать патч
Небезызвестный среди пользователей ОС Linux планировщик BFS портирован в ОС FreeBSD в рамках Google Summer Of Code (порт отличается от Linux-оригинала). Первоначально BFS был портирован в восьмую ветку FreeBSD, в настоящее время также доступны патчи для FreeBSD 9 CURRENT BETA1. Для самых ленивых доступен Live CD с уже пропатченым ядром.
Использование BFS должно увеличить отзывчивость системе (это актуально, в основном, на десктопах).
Все, кому небезразлична FreeBSD, а также просто заинтересовавшиеся, приглашаются к тестированию. Если оно закончится успешно, есть вероятность, что патч примут в основную ветку разработки FreeBSD.
>>> Подробности
Кэспер Сэндберг (Kasper Sandberg) провёл сравнение производительности системы на последнем ядре (2.6.32) с BFS и со стандартным шедулером CFS. Тест показал первенство всё ещё не принятого в основную ветку творения Кона Коливаса (Con Kolivas) в кодировании видео.
Для сжатия видео использовался кодер x264, запущенный на четырёхядерном Core2 Quad Q9300. Каждый из трёх (низкая скорость кодирования, средняя и высокая) тестов запускался с различным числом потоков: от 1 до 16, с шагом один.
>>> Подробности
Представлены результаты измерения производительности планировщика задач BFS, нацеленного на увеличение отзывчивости системы.
Source opennet.ru
Т.о. получается, что CFS не идеальный планировщик, и, как говорил Кон Коливас, в особенности на задачах компиляции, BFS более полно использует возможности системы.
>>> Подробности
Con Kolivas вернулся с новым планировщиком задач для Линукс ядра BFS (Brain Fuck Scheduler). Цитата:
Почему я написал его?
После многих лет использования моего старого ядра [Линукса] и многочисленных обновлений железа, в конце концов у меня появилось оборудование, которое требовало новых драйверов ядра, а также мне хотелось попробовать новые файловые системы. Загрузка в стандартное ядро [основная ветка на kernel.org] была достаточно обнадёживающей в том, что поведение планировщика стало гораздо лучше, чем в старых ядрах. Однако, много времени не потребовалось, чтобы я разочаровался и в этом [планировщике]. Случайные зависания при движении курсора мыши и нажатиях клавиш, странное распределение процессорного времени при разных вариантах нагрузки на систему и непредсказуемое поведение - это всё то, что, я надеялся, уже исправили. Поэтому я сделал то, чего поклялся никогда не делать - изучил код [планировщика CFS в ядре]. Увидев, что он превратился в монстра невероятных размеров, я сел и поразмыслил, что же в нём не так.
Одна из основных особенностей "справедливости" и интерактивности, за которую я всегда ратовал — это простая семантика того, как должно распределяться процессорное время; с гарантированными низкими задержками так, чтобы интерактивность была гарантирована архитектурой системы, а не так, чтобы она была привинчена с краю [bolted on]. По сути CFS так и делает, но у CFS есть кое-что ещё. CFS варьирует отрезки времени с тем, чтобы попытаться сохранить список завершения задач и определяет распределение процессорного времени, основываясь на отношении работы, поделённой на отдых. CFS также спроектирован, чтобы работать на супер-компьютерах - то, что обычный человек никогда даже не увидит.
Все эти подсчёты времени сна - это то, что, как я обнаружил, ответственно за различное поведение системы при различных нагрузках на неё - то, что вызывает относительное "голодание" и нечестность распределения процессорного времени. Хотя, надо отдать должное, в CFS это не сильно выражено, и это замечательно. Но, тем не менее, поведение системы при работе CFS - это не то ощущение, которое я бы хотел получить при работе планировщика. Правильный планировщик должен "думать" только о будущем (не подсчитывая время сна), а CFS, увы, не загружает полностью достаточно ненагруженную систему с небольшим количеством процессоров.
Поэтому я всё выкинул и начал писать код, работающий приблизительно наоборот.
Что же это такое?
BFS - это аббревиатура от Brain Fuck Scheduler (позволю себе оставить без перевода). Он был разработан по принципу "гляжу только вперёд" и позволяет выжать максимум из достаточно слабых компьютеров, при этом он не ориентирован на суперкомпьютеры. BFS ориентирован на десктоп, имеет при этом по дизайну сверхнизкие задержки для великолепной интерактивности, вместо того, чтобы заниматься подсчётами, при этом BFS имеет настоящую "честность" (распределения процессорного времени), хорошее распределение уровней NICE и отличную масштабируемость при обычных нагрузках.
Отличная масштабируемость при обычных нагрузках? Разве тут нет противоречия?
Многие годы мы нагружали свои Linux системы так, чтобы работы было больше, чем у нас есть процессоров, потому что все мы считали, что jobservers ограничены в своих способностях по полному использованию процессоров (поэтому на 4х процессорном компьютере мы запускали компиляцию в шесть потоков). Мой планировщик доказал, что jobserver ни в чём не виноват, потому что на компьютере с 4 процессорами четыре потока при использовании BFS завершают работу быстрее, чем *любое* количество jobserver'ов при использовании CFS. Предлагаю вам посмотреть на графики обратной масштабируемости Сергея Беляшева, показывающие нагрузку на систему при разном количестве "задач" (jobs) на 4х ядерном компьютере. Планировщик задач в основном ядре никогда не может нагрузить машину полностью - он не может выжать максимум из вашей настольной системы ни при каких обстоятельствах. Отмечу, что этот график достаточно стар - масштабируемость с тех пор улучшилась.
Далее Кон объясняет выбор его имени (потому что, скорее всего, этот планировщик никогда не появится в основном ядре, и BFS не ориентирован на супер-компьютеры, например, на NUMA машины) и даёт рекомендации по его использованию (просто наложите патч на ядро).
>>> BFS Faq
