LINUX.ORG.RU

Новый планировщик процессов на основе BFS

 ,


1

2

Появился новый планировщик задач, основанный на коде BFS (Brain Fuck Scheduler), но с возможностью использования нескольких очередей выполнения.
BFS сам по себе использует только одну очередь выполнения для всех CPU. Это позволяет избежать накладных расходов на балансировку нагрузки, но не очень хорошо масштабируется.

Какие преимущества у нового планировщика по сравнению с другими планировщиками?

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

Какие у него недостатки по сравнению с другими планировщиками?

  • Он не является стабильным.
  • Он не проверялся ни на чём, кроме как на KVM с 4 CPU.
  • Многие функции еще не работают или не реализованы вовсе.

>>> Подробности

★★★★★

Проверено: post-factum ()
Последнее исправление: post-factum (всего исправлений: 5)

Ответ на: комментарий от true_admin

Это скорее тенденция чем прямая зависимость. Можно объявить переменную, положить в неё результат работы функции и потратить на это несколько строк а можно заменить переменную функцией и каждый раз вычислять одно и тоже значение заново.

Napilnik ★★★★★
()

Не нужно!

Deleted
()
Ответ на: комментарий от Boy_from_Jungle

return 1;

EXIT_SUCCESS уже не модно писать?

А давно ли EXIT_SUCCESS = 1?????

svu ★★★★★
()
Ответ на: комментарий от true_admin

«при прочих равных» я не просто так указал

А в том примере, что тебе привели, всё «прочее» было равно на 100%, даже сравнивать не надо. Тут единственное отличие было именно в кол-ве строк. Их меньше, а результат - хуже.

anonymous
()
Ответ на: комментарий от smolnij

В него добавили масштабирование которое на десктопе никому не впилось.

XXI век на дворе, восьмиядерные процессоры в каждом лабазе, Смольный всё ещё получает телефонограммы для Ленина?

anonymous
()
Ответ на: комментарий от anonymous

А в том примере, что тебе привели, всё «прочее» было равно на 100%

кроме читабельности. Или ты все программы в одну строчку пишешь?

true_admin ★★★★★
()

народ, немного не по теме - но подскажите плиз, для ОДНОЯДРЕННОЙ машины какой лучше планировщик сейчас использовать ?

anonymous
()
Ответ на: Ля ля ля... от anonymous

В твоём примере условия совсем-совсем неравные. Если бы ты был разработчиком, «сомнительное преимущество» было бы тебе понятно. А сейчас ты споришь о теме, в которой ничерта не понимаешь. Это не возбраняется, просто толку нет.

ForwardToMars
()
Ответ на: комментарий от true_admin

Пример был утрированный. Разумеется, в одну строчку ни кто не пишет. Но можно написать

if (a)
{

  if (b)
  {
    return;
  }
  else
  {
   printf("aaa\n");
  }

}
или
if (a) {
  if (b)
    return;
  else
    printf("aaa\n");
}
И вот, ни читабельность не изменилась, ни функциональность, а строк стало меньше, но лучше не стало ни кому. Кол-во строк - это очень опосредованный показатель. Да и «при прочих равных» - настолько расплывчато, что лучше и не использовать. Есть два планировщика, написанных разными людьми - это подпадает под «при прочих равных»?

anonymous
()
Ответ на: комментарий от anonymous

«при прочих равных» - настолько расплывчато

да, это я зря сказал. При условии что нет других доступных метрик кода я выбираю тот код что короче. Это всё что я хотел сказать.

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

А какую нишу должен занять этот принципиально новый планировщик?

Нишу ещё одного планировщика, что тут не ясно :) Мода такая нынче, 7 планировщиков, 15 наутилусов, 4 гнома... Цифры конечно от балды, но вы поняли.

Lennier ★★★★
()
Ответ на: комментарий от true_admin

[offtop]

да, это я зря сказал.

Нельзя быть настолько вменяемым модератором. Отстранят же за неполное служебное соответствие.

[/offtop]

BFS (Brain Fuck Scheduler)

CPU-Scheduler based on BFS by Con Kolivas

Я путаю, или это изначально толсто даже для lkml? :)

another ★★★★★
()

Появился новый планировщик задач

Многие функции еще не работают или не реализованы вовсе.

/0

segfault ★★★★★
()
Ответ на: комментарий от another

даже для lkml? :)

Нет ничего такого что нельзя было бы отправить в lkml :)

Больше велосипедов больших и разных. Не все опен-сурц проекты добились успеха (мягко говоря), но те что добились очень часто были наколенными поделками. Может и этот парень что-нить придумает что в cfs упрут.

К слову, у меня на арче (а ядро у них ванильное, кроме двух эстетических патчей, если не путаю) во время io мышка замирает. Так что есть ещё куда стремиться.

true_admin ★★★★★
()
Ответ на: комментарий от d_Artagnan

Прежде чем отвечать на чье-то сообщение неплохо бы его прочитать. Под прочитать я имею ввиду не выхватить интересующую вас часть сообщения и потом с умным видом тыкать палочкой в только вам понятные умозаключения. Если вы попробуете напряч остатки мозга и прочтете строку

при прочих равных чем меньше строк тем лучше

то возможно... возможно вы заметите три слова «при прочих равных», возможно конечно что вы далеки от обсуждаемой темы(да так оно и есть), но хотелось бы узнать _где вы видели чтобы в ядре так форматировали код_ !?! int main(int argc, char** argv){ printf(«Hi faggot»); кeturn 1;}

Kage
()
Ответ на: комментарий от true_admin

Если бы ты писал код то знал бы что small code base поддерживать и развивать легче чем large code base.

Это скорее империческое правило, чем осмысленная теория.

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

AVL2 ★★★★★
()
Ответ на: комментарий от true_admin

при прочих равных чем меньше строк тем лучше

4.2 если ты про C.

drBatty ★★
()
Ответ на: комментарий от true_admin

«при прочих равных» я не просто так указал

даже с жёстким гайдлайном, который заставляет тебя писать один оператор в одной строке, это всё равно 4.2. Попробуй реализовать скажем сортировку. Пузырёк простой, но ОЧЕНЬ медленный. Простая вставка чуть сложнее, но таки побыстрее. Qsort обычно намного быстрее, но и строк таки больше в разы. IRL обычно юзают Qsort + простые вставки. Как видишь, даже для элементарной задачи, чем меньше строк, тем хуже.

drBatty ★★
()
Ответ на: комментарий от Boy_from_Jungle

EXIT_SUCCESS уже не модно писать?

ему тут надо было EXIT_FAILURE

drBatty ★★
()
Ответ на: комментарий от true_admin

Если бы ты писал код то знал бы что small code base поддерживать и развивать легче чем large code base.

а самокат более ремонтопригоден, чем велосипед, а тем более - мотоцикл. И что?

drBatty ★★
()
Ответ на: комментарий от anonymous

народ, немного не по теме - но подскажите плиз, для ОДНОЯДРЕННОЙ машины какой лучше планировщик сейчас использовать ?

ваниль.

drBatty ★★
()
Ответ на: комментарий от anonymous

а можно написать

if (a)
/*
это самый хороший

код

Ня!

Я его написал. 

всем чмоки!

Если что - пишите на мою
СТРАНИЧКУ
фконтакте


*/
{
// начинаем условный блок (если)

  if (b)// если б не 
// рано нулю 
// точнее
// не равно false

// или равно Ъ, я 


//точно не помню

//я спрасил у друга


//вроде без
// разгницы

//я завтра допишу

drBatty ★★
()
Ответ на: комментарий от drBatty

а самокат более ремонтопригоден, чем велосипед, а тем более - мотоцикл. И что?

у них разное назначение

Пузырёк простой, но ОЧЕНЬ медленный.

если пузырёк подходит для задачи то пусть будет пузырёк

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Если бы ... = ОБС

Первичен здесь код и его «доступность для понимания», а его количество вторично. Или вы и вправду думаете, что при схожем функционале и равной или почти равной «доступности» объем кода может очень существенно отличаться?

Кстати, а ООП провалилось или нет? (В рамках code base)

anonymous
()
Ответ на: Если бы ... = ОБС от anonymous

ты дальше тред почитай

Кстати, а ООП провалилось или нет? (В рамках code base)

это уже у кого какие руки и какой ЯП выбран.

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

Это скорее вопрос кодинг-стайла. ядро имеет строго оговоренный кодинг-стайл и два абсолютно одинаковых (с точностью до форматирования и не влияющих на семантику особенностей языка) фрагмента кода должны выгдлядеть ОДИНАКОВО.

anonymous
()
Ответ на: комментарий от true_admin

у них разное назначение

у них одно назначение. Просто в самокате фич меньше.

если пузырёк подходит для задачи то пусть будет пузырёк

ага. Быдлокодер детектед. Пузырьковая сортировка по всем показателям хуже любой другой. Единственное её преимущество: она понятна любому идиоту. Твой код читают идиоты?

drBatty ★★
()
Ответ на: комментарий от drBatty

у них одно назначение. Просто в самокате фич меньше.

На самокате я не смогу доехать из города А в город Б. Или это тоже «фича»? Так можно и самолёт сравнить с самокатом, он тоже транспортное средство.

Твой код читают идиоты?

Да я сам не ахти какой кодер. Но за время работы на дедиках когда приходилось по запросу клиентов лазить в код php и pecl, mysql, питона, sphinx, freebsd и многих прочих вещей начал ценить простой код. Просто потому что разобраться и допилить легче.

И вот мне нравится когда код написан так что _даже я_ могу залезть и разобраться в нём.

true_admin ★★★★★
()
Ответ на: комментарий от Kage

Караул

Если бы вы не вкладывали в фразу «при прочих равных» сакрального смысла и использовали ее по назначению, то не было бы повода для болтовни :)

А фраза «при прочих равных» уже сама намекает, о весомости этого, с позволения сказать, преимущества :)

Два мешка. В них два кота. - Вам какой? - А глянуть можно, кот ли там? - А вот фиг вам! - А, ну тогда мне тот, что полегче :)

P.S. На правах стеба. А где вы видели, чтобы «_»=«{знак_пунктуации}» ? Или вы как и true_admin таким своеобразным образом оптимизируете объем кода/предложения. За вас часом AI еще код не пишет.

anonymous
()

судя из расшифровки аббревиатуры лучше с ним не связываться

GOD ★★★
()
Ответ на: комментарий от drBatty

Ну а что, хороший код :)

За одни чмоки можно многое простить :) А тут еще и страничка в «фконтакте». Нет, ну ей богу, всем бы так. А то не успеешь задашь вопрос, а тебя уже на RTFM послали!

P.S. А вообще ЛОР развивает. anonymous к примеру, учится разгадывать такую CAPTCHA

anonymous
()
Ответ на: комментарий от true_admin

Почитал ветку ... ?
Еще раз почитал ветку ... ???
... (... n-2 раз) ...

Эврика! Я понял! Писать компактный код необязательно, достаточно оставить пометку:
//Если что-то не работает, ищите ошибку здесь!
А для ребят с ЛОРа можно еще и так:
/*
Если что-то не работает, ищите ошибку здесь!
Значит Вася - ХХХ. Ты слышишь, Вася, ты - ХХХ. Это этот ХХХ мне подсказал так написать. Ошибка точно здесь, т.к. в своем коде я уверен. */

P.S. Забавное совпадение - как я понял, причина написания «нового планировщика» полностью совпадает с вашим мнением. У вас невероятная проницательность :) И замечание drBatty о алгоритмах почти к месту.

P.P.S. Сегодня CAPTCHA просто зверь!

anonymous
()
Ответ на: комментарий от anonymous

Тебе наверно кажется что ты написал остроумный комментарий про, кхм, комментарии к коду. Очевидно что я имел в виду что-то вроде этого: http://antjanus.com/blog/web-design-tips/best-comment-separator/

По поводу простоты и краткости это называется keep it simple, stupid. Вторая вещь которую я доносил это premature optimization. Всё.

Всегда можно придумать кучу частных контр-примеров когда это не работает, чем вы и занимаетесь. Это не делает мои рассуждениями в корне неправильными или неприменимыми.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

На самокате я не смогу доехать из города А в город Б. Или это тоже «фича»? Так можно и самолёт сравнить с самокатом, он тоже транспортное средство.

когда мне говорят, что форкнули самокат, и теперь в нём деталей столько-же, но он - мотоцикл, меня терзают смутные сомнения...

Да я сам не ахти какой кодер. Но за время работы на дедиках когда приходилось по запросу клиентов лазить в код php и pecl, mysql, питона, sphinx, freebsd и многих прочих вещей начал ценить простой код. Просто потому что разобраться и допилить легче.

И вот мне нравится когда код написан так что _даже я_ могу залезть и разобраться в нём.

ППКС.

но вот посмотри на каноничный пример qsort в одну строчку:

qsortOneLine s = case s of{[]->[];(x:xs)->qsortOneLine [y | y<-xs, y<x] ++ x : qsortOneLine [y | y<-xs, y>=x]}
Глядя на эту строчку, я чувствую себя идиотом. А ты? А вот qsort на C для меня проста и понятно. Хотя там сотня строк. Я тебе больше скажу: эта строчка по времени работает примерно также «быстро», как и сортировка пузырьком. И дело тут не в ЯП, а опилках, которые заменяют мозг автора. Продолжишь доказывать, что мало строк == просто и понятно?

drBatty ★★
()
Ответ на: комментарий от anonymous

Эврика! Я понял! Писать компактный код необязательно, достаточно оставить пометку: //Если что-то не работает, ищите ошибку здесь!

ты будешь смеяться, но IRL я часто такие коменнты делаю. FIXME даже vim знает...

И замечание drBatty о алгоритмах почти к месту.

ты возможно не понял, но я намекал на то, что если код занимает мало строк, то это либо макароны writeonly, либо непродуманный код который тормозит и глючит. Либо и то и другое.

drBatty ★★
()
Ответ на: комментарий от true_admin

Вторая вещь которую я доносил это premature optimization.

вот эта твоя premature optimization на практике всегда выражается в УМЕНЬШЕНИЕ числа строк. Т.е. если тебе надо сделать А, а потом сделать Б, то ты потратишь 100+100 строк. Но если применить premature optimization, то ты напишешь 150 строк, которые делают и А и Б сразу. На первый взгляд это быстрее и лучше, но только на первый. На второй замечаешь, что поддерживать и дорабатывать такую ерунду на порядок тяжелее. Но это не самое печальное: на самом деле, компилятор достаточно умный, что-бы самостоятельно совместить А и Б (если это даёт профит конечно), в итоге, два простых куска кода работают даже быстрее, чем один сложный.

По поводу простоты и краткости это называется keep it simple, stupid.

разве два куска кода, для А и для Б сложнее, чем один, который делает А и Б? Почти всегда - проще. И почти всегда длиннее.

drBatty ★★
()
Ответ на: комментарий от drBatty

Глядя на эту строчку, я чувствую себя идиотом. А ты?

а для меня всё просто и понятно, я потратил три недели своей жизни на хаскель :) особенно в такой форме: http://lurkmore.so/images/3/3d/Cmp.jpg

Зная алгоритм (берём элемент X и отдельно рекурсивно сортируем те элементы что больше X и что меньше) я понимаю что раз у нас X посередине значит всё что слева и справа это элементы больше и меньше X которые рекурсивно сортируются.

В общем, это не понятно только тем кто хаскель не знает :). Хотя я много времени потратил чтобы понять как это работает и уметь воспроизводить без шпаргали. Но сейчас сишный вариант кажется ужасным и менее понятным. Кстати, list comprehension есть, похоже, почти во всех новых ЯП ибо это удобно.

вот эта твоя premature optimization на практике всегда выражается в УМЕНЬШЕНИЕ числа строк.

это не то что ты думаешь. Это когда берутся оптимизировать те куски кода которым скорость не нужна. Это лишний код, более сложный код, ненужный код.

если тебе надо сделать А, а потом сделать Б, то ты потратишь 100+100 строк.

напишешь 150 строк, которые делают и А и Б сразу

Я не об этом. Одна из самых распространённых ошибок это излишняя абстракция. Например, люди часто делают сайты с дополнительной абстрактной прослойкой под базу чтобы можно было запускать сайт и на mysql и на postgres. После чего всю жизнь сайт работает на мускле. Лишний груз кода.

Или начинают городить свои врапперы к месту и не к месту, «авось пригодится».

true_admin ★★★★★
()
Ответ на: комментарий от Kage

Сколько КО, страждущих ткнуть в носом конкретику...

Вы тут уже третий или пятый пионер, считающий своим святым долгом ткнуть в к-л факт, совершенно не уловив сути.

d_Artagnan ★★
()
Ответ на: комментарий от true_admin

Зная алгоритм (берём элемент X и отдельно рекурсивно сортируем те элементы что больше X и что меньше) я понимаю что раз у нас X посередине значит всё что слева и справа это элементы больше и меньше X которые рекурсивно сортируются.

1. почему «посередине»?

2. что делать с проблемой сортировки маленьких подмассивов?

Давай посмотрим на _рабочий_ код, а не сферический прототип? Ну или попробуй сравнить время выполнения qsort(3) и этих программ с твоей картинки.

В общем, это не понятно только тем кто хаскель не знает :). Хотя я много времени потратил чтобы понять как это работает и уметь воспроизводить без шпаргали. Но сейчас сишный вариант кажется ужасным и менее понятным. Кстати, list comprehension есть, похоже, почти во всех новых ЯП ибо это удобно.

та я знаю. Только тут вообще-то массив, а не список, и применение операции для списка к массиву - это несколько не экономично. Ты не подумал, что сишная реализация меняет только те элементы, которые стоят неправильно, а то, что на хаскеле создаёт новый список, и перебрасывает туда ВСЕ элементы? Не думаешь о том, что ТАКАЯ реализация на сишных указателях будет ненамного сложнее?

for(p = x0; p < x1; p++)
    *p < m ? *t0++ = *p++ : *t1-- = *p++;
вот тебе твой list comprehension, только сдвоенный. Смысл работы такой-же, разве что я использую один временный массив t, а ты используешь два временных массива(потому тебе пришлось дважды применить list comprehension). Оно конечно проще, только это ДРУГОЙ алгоритм, который ещё N памяти хочет. А qsort это сортировка _на месте_. Если ты не знал, для таких требований по памяти есть другие алгоритмы, по сравнению с которыми qsort сосёт. Например radix требует N эл-тов временно и ещё 256 целых. И сортирует по однобайтовому ключу за O(N). Применяя её 4 раза, можно отсортировать за O(N) массив 32х битных целых. А qsort даёт время только O(N*log(N)) и то в идеале (худший случай O(N^2)).

это не то что ты думаешь. Это когда берутся оптимизировать те куски кода которым скорость не нужна. Это лишний код, более сложный код, ненужный код.

ага. Либастрал одолжишь? А то я вот пишу сортировку, и не знаю, нужна там оптимизация, или не нужна? Есть у программы лишние N*4 байта, или нет?

Я не об этом. Одна из самых распространённых ошибок это излишняя абстракция. Например, люди часто делают сайты с дополнительной абстрактной прослойкой под базу чтобы можно было запускать сайт и на mysql и на postgres. После чего всю жизнь сайт работает на мускле. Лишний груз кода.

ну а зачем мне обобщённый список-массив из твоего хаскеля? Зачем мне сортировка, которая тормозит как пузырёк, и жрёт немеренно памяти? Это по твоему не излишняя абстракция? Или взять массивы из пхп, которые и списки, и массивы, и очереди, и деревья, и хеши, и всё это сразу, и всё это одинаково криво и жутко медленно? Ну разве что строчки экономить...

drBatty ★★
()
Ответ на: комментарий от true_admin

при прочих равных чем меньше строк тем лучше

При прочих равных. Но уменьшение токенов в строке лучше сказывается на читаемости, чем уменьшение числа строк :)

KRoN73 ★★★★★
()
Ответ на: комментарий от drBatty

Только тут вообще-то массив, а не список, и применение операции для списка к массиву - это несколько не экономично.

Ты не с этого начал. Ты сказал что код тебе не понятен. Теперь, оказывается, понятен.

А то я вот пишу сортировку, и не знаю, нужна там оптимизация, или не нужна? Есть у программы лишние N*4 байта, или нет?

а я пишу программы, а не сферические компоненты и я заранее знаю есть там лишняя память или нет.

true_admin ★★★★★
()

Brain Fuck Scheduler

Я как-то раньше не задумывался, как это расшифровывается. Но теперь, кажется, понятно, почему Линус не хочет включать ЭТО в ядро.

hobbit ★★★★★
()
Ответ на: комментарий от tazhate

Это петросянство или ты не понимаешь, о чем говоришь?

Главный Петросян здесь, судя по всему, Кон Коливас. А все остальные, в т.ч. твой оппонент - так, мелкие Петросянчики.

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

hobbit ★★★★★
()
Ответ на: комментарий от true_admin

Ты не с этого начал. Ты сказал что код тебе не понятен. Теперь, оказывается, понятен.

дык ты же для меня его понятно и просто переписал. И я ВНЕЗАПНО понял, что это ДРУГОЙ алгоритм. Разве ты не знаешь, что у любого алгоритма есть своя цена? Есть время выполнения, есть требования по памяти? Разве ты не знаешь, что qsort работает быстро только если N велико, а иначе рулят более простые алгоритмы? Разве ты не понимаешь, что если N у тебя велико, то требования по памяти и по времени становятся важными, и от них не отмахнуться? Ну а почему ты ровняешь алгоритм, который НЕ требует дополнительной памяти, и который изменяет данные только если оно надо, с алгоритмом, который требует N (большое!) памяти, и тупо переписывает ВСЁ?

а я пишу программы, а не сферические компоненты и я заранее знаю есть там лишняя память или нет.

я уже заметил - у тебя полно памяти лишней, а ты зачем-то сортировку qsort юзаешь, несмотря на то, что она твою программу повесить может.

drBatty ★★
()
Ответ на: комментарий от drBatty

Разве ты не знаешь, что qsort работает быстро только если N велико, а иначе рулят более простые алгоритмы?

По твоей логике ничего кроме ассемблера не нужно ибо остальное крадёт скорость и ворует память. Подумай почему очень много софта уже написано на скриптовых языках. Да потому что у комьютеров уже не 640кб памяти и прикладных задач которым нужно постоянно много скорости и памяти очень мало.

У меня комп 99% времени простаивает и это общемировой тренд. Я задумываюсь о скорости только когда её не хватает. А ты сражаешься с ветряными мельницами.

true_admin ★★★★★
()
Ответ на: комментарий от hobbit

Главный Петросян здесь, судя по всему, Кон Коливас

ну так в хорошем же смысле.

Кон дал такое имя своему детищу, заставляет подозревать, что он изначально хотел его виеть заведомо непринимаемым в ядро.

я сильно сомневаюсь что Линус покраснел когда прочитал расшифровку акронима. Да и grep -ri fuck ./ подсказывает что остальным тоже не привыкать.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Сам он наверняка не покраснел, но он уже одной ногой в энтерпрайзе и заботится о своей репутации.

hobbit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.