BSDPORTAL.RU :: Повышение степени интерактивности планировщика ULE • Использование BSD как Desktop, игры.

--- sched_ule.c.orig 2011-10-22 11:40:30.000000000 +0300
+++ sched_ule.c 2011-11-03 18:36:11.000000000 +0200
@@ -2118,6 +2118,14 @@
struct td_sched *ts;

THREAD_LOCK_ASSERT(td, MA_OWNED);
+ if (td->td_pri_class & PRI_FIFO_BIT)
+ return;
+ ts = td->td_sched;
+ /*
+ * We used up one time slice.
+ */
+ if (--ts->ts_slice > 0)
+ return;
tdq = TDQ_SELF();
#ifdef SMP
/*
@@ -2144,9 +2152,6 @@
if (TAILQ_EMPTY(&tdq->tdq_timeshare.rq_queues[tdq->tdq_ridx]))
tdq->tdq_ridx = tdq->tdq_idx;
}
- ts = td->td_sched;
- if (td->td_pri_class & PRI_FIFO_BIT)
- return;
if (PRI_BASE(td->td_pri_class) == PRI_TIMESHARE) {
/*
* We used a tick; charge it to the thread so
@@ -2157,11 +2162,6 @@
sched_priority(td);
}
/*
- * We used up one time slice.
- */
- if (--ts->ts_slice > 0)
- return;
- /*
* We're out of time, force a requeue at userret().
*/
ts->ts_slice = sched_slice;

/*
* We run the long term load balancer infrequently on the first cpu.
*/
if (balance_tdq == tdq) {
if (balance_ticks && --balance_ticks == 0)
sched_balance();
}

/*
* Save the old switch count so we have a record of the last ticks
* activity. Initialize the new switch count based on our load.
* If there is some activity seed it to reflect that.
*/
tdq->tdq_oldswitchcnt = tdq->tdq_switchcnt;
tdq->tdq_switchcnt = tdq->tdq_load;
/*
* Advance the insert index once for each tick to ensure that all
* threads get a chance to run.
*/
if (tdq->tdq_idx == tdq->tdq_ridx) {
   tdq->tdq_idx = (tdq->tdq_idx + 1) % RQ_NQS;
   if (TAILQ_EMPTY(&tdq->tdq_timeshare.rq_queues[tdq->tdq_ridx]))
      tdq->tdq_ridx = tdq->tdq_idx;
}

static void
sched_balance(void)
{
struct tdq *tdq;

/*
* Select a random time between .5 * balance_interval and
* 1.5 * balance_interval.
*/
balance_ticks = max(balance_interval / 2, 1);
balance_ticks += random() % balance_interval;
if (smp_started == 0 || rebalance == 0)
return;
tdq = TDQ_SELF();
TDQ_UNLOCK(tdq);
sched_balance_group(cpu_top);
TDQ_LOCK(tdq);
}

#ifdef SMP
/*
* We run the long term load balancer infrequently on the first cpu.
*/
if (balance_tdq == tdq) {
if (balance_ticks && --balance_ticks == 0)
sched_balance();
}
#endif

FreeBSD 9.0-RC1 GENERIC i386
Одноголовый p4 prescott

last pid: 56787; load averages: 4.19, 3.58, 2.35 up 0+00:21:14 10:21:06
125 processes: 5 running, 118 sleeping, 2 zombie
CPU: 69.8% user, 4.3% nice, 24.7% system, 1.2% interrupt, 0.0% idle
Mem: 605M Active, 64M Inact, 239M Wired, 33M Cache, 110M Buf, 38M Free
Swap: 4096M Total, 6296K Used, 4090M Free

PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
55751 root 1 75 0 35028K 24940K RUN 0:03 11.57% cc1
56633 root 1 73 0 22812K 16996K RUN 0:00 4.79% cc1
56597 ankor 1 91 19 46988K 10664K RUN 0:00 1.27% nepomukindexer
1942 root 1 20 0 338M 319M select 0:33 1.17% Xorg
2039 ankor 3 52 0 237M 62584K select 0:20 1.07% kdeinit4
2111 ankor 8 20 0 116M 34000K select 0:18 0.49% kaffeine-xbu
3010 ankor 18 20 0 158M 69036K uwait 0:21 0.00% firefox-bin
2173 ankor 2 52 0 144M 45040K select 0:12 0.00% kdeinit4
2040 ankor 6 20 0 179M 37596K select 0:12 0.00% knotify4
2095 ankor 7 39 19 77916K 43616K uwait 0:07 0.00% virtuoso-t
2034 ankor 3 52 0 136M 44144K uwait 0:05 0.00% kwin
2063 ankor 12 39 19 118M 37412K uwait 0:04 0.00% nepomukservicestub
24373 root 1 34 0 40448K 27172K wait 0:04 0.00% ruby18
32542 ankor 5 20 0 168M 70748K select 0:03 0.00% soffice.bin
2110 ankor 3 20 0 88356K 36400K kqread 0:03 0.00% kaffeine

Автор:	fidaj [ Пн 31 окт, 2011 11:48 pm ]
Заголовок сообщения:	Повышение степени интерактивности планировщика ULE
Если при сборке мира, ядра, портов в несколько потоков (>=2ncpu) вас раздражает то, что система перестает мгновенно реагировать на ваши действия - то эта тема для вас. Все "прелести" интерактивности я начал замечать при переходе на 7.х, когда появился нашумевший планировщик ULE. Говорят что идеология ULE была перенесена в планировщик Mac OS X 10.6, но почему то там я не замечаю (на одном и том же железе) такие тормоза при большой нагрузке на CPU, какие есть во FreeBSD, к моему огромному сожалению... Именно поэтому я и подхватил интересную тему с нашумевшим в Linux планировщике BFS и попытался сделать порт под CURRENT И демонстрировал полученный результат. При этом смотрел в код всех трех планировщиков - пытаясь понять чем они занимаются... многое конечно не понял, но это дело времени... Потом посмотрел в ULE и сделал некоторые незначительные, но важные для интерактивности изменения http://docs.freebsd.org/cgi/mid.cgi?201 ... 7.35db5ccd Код:* --- sched_ule.c.orig 2011-10-22 11:40:30.000000000 +0300 +++ sched_ule.c 2011-11-03 18:36:11.000000000 +0200 @@ -2118,6 +2118,14 @@ struct td_sched ts; THREAD_LOCK_ASSERT(td, MA_OWNED); + if (td->td_pri_class & PRI_FIFO_BIT) + return; + ts = td->td_sched; + / + * We used up one time slice. + / + if (--ts->ts_slice > 0) + return; tdq = TDQ_SELF(); #ifdef SMP / @@ -2144,9 +2152,6 @@ if (TAILQ_EMPTY(&tdq->tdq_timeshare.rq_queues[tdq->tdq_ridx])) tdq->tdq_ridx = tdq->tdq_idx; } - ts = td->td_sched; - if (td->td_pri_class & PRI_FIFO_BIT) - return; if (PRI_BASE(td->td_pri_class) == PRI_TIMESHARE) { /* * We used a tick; charge it to the thread so @@ -2157,11 +2162,6 @@ sched_priority(td); } /* - * We used up one time slice. - / - if (--ts->ts_slice > 0) - return; - / * We're out of time, force a requeue at userret(). */ ts->ts_slice = sched_slice; Уже отреагировали на мое сообщение в рассылке, поэтому прошу сообщество, кто имеет возможность, желание: - опробовать мой патч на своей системе; - провести всевозможные сравнительные тесты (доступные вам) и предоставить любые результаты; - написать письмо в свободной форме и на доступном вам английском в ту же тему в рассылке и рассказать о своих впечатлениях. - укажите ваш CPU (желательно полную модель)... Кое-что, конечно, можем пообсуждать здесь... P.S. граждане, напишите пожалуйста, в такой форме: Наблюдаю/Не наблюдаю проблему с подвисаниями на ULE CPU:<модель> Спасибо!

Автор:	ankor [ Вт 01 ноя, 2011 12:10 pm ]
Заголовок сообщения:
У меня FreeBSD 9.0-RC1 GENERIC i386 Могу потестить, если подойдёт. Перепробовал все планировщики, остановился на 4BSD. При сборке из портов Firefox и Thunderbird система лезет в подкачку более чем на 1G ( в наличии 1G) с ULE в ступоре, c BFS приступ эпилепсии с 4BSD тормозит, но работать можно. Можно отдать должное BFS, отзывчивость отличная, если в подкачку не лезет.

Автор:	arrowdodger [ Вт 01 ноя, 2011 3:44 pm ]
Заголовок сообщения:
Я так понимаю, переносом этих двух ифов вы исключили sched_balance(); Код: /* * We run the long term load balancer infrequently on the first cpu. / if (balance_tdq == tdq) { if (balance_ticks && --balance_ticks == 0) sched_balance(); } и внесение изменений в очередь потоков Код:* /* * Save the old switch count so we have a record of the last ticks * activity. Initialize the new switch count based on our load. * If there is some activity seed it to reflect that. / tdq->tdq_oldswitchcnt = tdq->tdq_switchcnt; tdq->tdq_switchcnt = tdq->tdq_load; / * Advance the insert index once for each tick to ensure that all * threads get a chance to run. */ if (tdq->tdq_idx == tdq->tdq_ridx) { tdq->tdq_idx = (tdq->tdq_idx + 1) % RQ_NQS; if (TAILQ_EMPTY(&tdq->tdq_timeshare.rq_queues[tdq->tdq_ridx])) tdq->tdq_ridx = tdq->tdq_idx; } , правильно? Можете пояснить почему это резко увеличивает отзывчивость и безопасно ли это делать?

Автор:	olexande [ Вт 01 ноя, 2011 10:33 pm ]
Заголовок сообщения:
Использую пока "штатный" На CoreQuad с 4Гб "залипания мыши" тоже бывают. Пока не пробовал менять планировщик. Думаю приссоединиться и попробовать чуть позже.

Автор:	arksu [ Ср 02 ноя, 2011 7:49 am ]
Заголовок сообщения:
поставил патч на 9.0 RC1 пока полет нормальный. субъективно поведение системы стало заметно лучше.

BSDPORTAL.RU http://bsdportal.ru/

Повышение степени интерактивности планировщика ULE http://bsdportal.ru/viewtopic.php?f=25&t=24900	Страница 1 из 1

Автор:	fidaj [ Ср 02 ноя, 2011 10:16 pm ]
Заголовок сообщения:
arrowdodger писал(а): Я так понимаю, переносом этих двух ифов вы исключили sched_balance() и внесение изменений в очередь потоков; ... , правильно? нет. ничего я не исключал, я изменил очередность проверок - перенес проверки необходимости ребалансировки (if (--ts->ts_slice > 0)) и флага высокоприоритетных нитей (if (td->td_pri_class & PRI_FIFO_BIT)) раньше самой балансировки... - что на мой взгляд логичнее... тем самым планировщик для таких случаев не ощуществляет рутину пересчетов статистики использования CPU... Код: static void sched_balance(void) { struct tdq tdq; / * Select a random time between .5 * balance_interval and * 1.5 * balance_interval. / balance_ticks = max(balance_interval / 2, 1); balance_ticks += random() % balance_interval; if (smp_started == 0 \|\| rebalance == 0) return; tdq = TDQ_SELF(); TDQ_UNLOCK(tdq); sched_balance_group(cpu_top); TDQ_LOCK(tdq); } тем более что в НЕ SMP системе участок кода Код:* #ifdef SMP /* * We run the long term load balancer infrequently on the first cpu. */ if (balance_tdq == tdq) { if (balance_ticks && --balance_ticks == 0) sched_balance(); } #endif и так не используется arrowdodger писал(а): Можете пояснить почему это резко увеличивает отзывчивость... ну резко или не резко... это субъективно... посмотрите где используется функция sched_clock() - чем раньше из нее выйти - тем быстрее будет разлочиваться поток/нить в statclock... плюс ко всему - я не знаю на сколько быстро выполняется функция random() и какой метод генерирования псевдослучайных последовательностей она использует (хотя и можно поинтересоваться)... может вообще аппаратный... в том числе и при задействовании аппаратного таймера... и вопрос - насколько быстро это все происходит? Я знаю что надежные программные генераторы (с большим периодом) - они очень медленные... Возможно по этим причинам (в том числе) повышается степень интерактивности... arrowdodger писал(а): ... и безопасно ли это делать? безопасно для чего именно... в каком смысле - не понял...

Автор:	fidaj [ Ср 02 ноя, 2011 10:18 pm ]
Заголовок сообщения:
arksu писал(а): поставил патч на 9.0 RC1 пока полет нормальный. субъективно поведение системы стало заметно лучше. в соседнем форуме вы ответили кое-что другое...

Автор:	AlexVPetrov [ Чт 03 ноя, 2011 9:30 am ]
Заголовок сообщения:
Поставил патч: Увеличилась отзывчивость десктопа (KDE), даже при больших нагрузках - сборка чего-либо. Вчера смотрел фильм в vlc при запущенной сборке KDE 4.7.3 - заметил только пару-тройку незначительных притормаживаний на доли секунды. Раньше при сборке смотреть видео было невозможно - видео и звук могли останавливаться на единицы секунд. fidaj, отличная работа!

Автор:	arrowdodger [ Чт 03 ноя, 2011 10:43 am ]
Заголовок сообщения:
Цитата: я изменил очередность проверок - перенес проверки необходимости ребалансировки (if (--ts->ts_slice > 0)) и флага высокоприоритетных нитей (if (td->td_pri_class & PRI_FIFO_BIT)) раньше самой балансировки... - что на мой взгляд логичнее... тем самым планировщик для таких случаев не ощуществляет рутину пересчетов статистики использования CPU... М, я вижу что Вы серьезно разобрались в коде и понимаете что делаете. В этом случае, патч действительно выглядит логичным. Несколько комментариев: 1. Касательно блока внутри #ifdef SMP - я так понимаю, он занимает приличное время из-за которого sched_clock() не возвращает и мютекс не разлочивается, правильно? Но там же в комментарии написано Цитата: We run the long term load balancer infrequently on the first cpu. Infrequently - не часто. Без Вашего патча мы наблюдаем, что управление туда как раз весьма часто попадает, из-за чего все тормозит. Так вот я к чему - быть может баг именно в проверке надо ли нам вызывать sched_balance()? 2. Т.к. в обоих ифах, которые Вы перенесли повыше не используется tdq, то их можно подвинуть и еще выше перед Код: tdq = TDQ_SELF(); Конечно, это не ахти что, но я не смотрел содержание макроса TDQ_SELF(), вдруг там какая-нибудь тяжеленькая операция. В скором времени поставлю Ваш патч на 9-STABLE.

Автор:	fidaj [ Чт 03 ноя, 2011 12:07 pm ]
Заголовок сообщения:
arrowdodger писал(а): М, я вижу что Вы серьезно разобрались в коде и понимаете что делаете. Вы мне льстите - я только-только осваиваю... arrowdodger писал(а): Несколько комментариев: 1. Касательно блока внутри #ifdef SMP - я так понимаю, он занимает приличное время из-за которого sched_clock() не возвращает и мютекс не разлочивается, правильно? Но там же в комментарии написано Цитата: We run the long term load balancer infrequently on the first cpu. Infrequently - не часто. Без Вашего патча мы наблюдаем, что управление туда как раз весьма часто попадает, из-за чего все тормозит. Так вот я к чему - быть может баг именно в проверке надо ли нам вызывать sched_balance()? возможно... но я пробовал через sysctl отключать kern.sched.balance, картина с тормозами не менялась... вероятно либо не правильно реализован алгоритм балансировки, либо не правильно определяется ядро CPU на котором выполняется нить в данный момент... arrowdodger писал(а): 2. Т.к. в обоих ифах, которые Вы перенесли повыше не используется tdq, то их можно подвинуть и еще выше перед Код: tdq = TDQ_SELF(); Конечно, это не ахти что, но я не смотрел содержание макроса TDQ_SELF(), вдруг там какая-нибудь тяжеленькая операция. хм... можно попробовать... но я пока тесты гоняю на текущем патче...хочу увидеть хоть косвенную картину... по тяжести - я все-таки склоняюсь к random()...

Автор:	fidaj [ Чт 03 ноя, 2011 10:42 pm ]
Заголовок сообщения:
граждане, напишите пожалуйста, в такой форме: Наблюдаю/Не наблюдаю проблему с подвисаниями на ULE CPU:<модель> Спасибо.

Автор:	fidaj [ Пт 04 ноя, 2011 1:21 am ]
Заголовок сообщения:
Прошу всех как можно больше дать ответов (а не только голосовать) на мою просьбу (у кого есть и у кого нет такой проблемы) потому что мне Jeff будет задавать вопросы и я ему должен что-то ответить.

Автор:	fidaj [ Пт 04 ноя, 2011 12:23 pm ]
Заголовок сообщения:
попрошу - активнее, пожалуйста. я хочу за сегодня подготовить ответ...

Автор:	ankor [ Пт 04 ноя, 2011 12:38 pm ]
Заголовок сообщения:
Применил патч. Код: FreeBSD 9.0-RC1 GENERIC i386 Одноголовый p4 prescott KDE 4.7.2 работает Kaffeine(on line radio) собираются 2 порта и ядро. Код: last pid: 56787; load averages: 4.19, 3.58, 2.35 up 0+00:21:14 10:21:06 125 processes: 5 running, 118 sleeping, 2 zombie CPU: 69.8% user, 4.3% nice, 24.7% system, 1.2% interrupt, 0.0% idle Mem: 605M Active, 64M Inact, 239M Wired, 33M Cache, 110M Buf, 38M Free Swap: 4096M Total, 6296K Used, 4090M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 55751 root 1 75 0 35028K 24940K RUN 0:03 11.57% cc1 56633 root 1 73 0 22812K 16996K RUN 0:00 4.79% cc1 56597 ankor 1 91 19 46988K 10664K RUN 0:00 1.27% nepomukindexer 1942 root 1 20 0 338M 319M select 0:33 1.17% Xorg 2039 ankor 3 52 0 237M 62584K select 0:20 1.07% kdeinit4 2111 ankor 8 20 0 116M 34000K select 0:18 0.49% kaffeine-xbu 3010 ankor 18 20 0 158M 69036K uwait 0:21 0.00% firefox-bin 2173 ankor 2 52 0 144M 45040K select 0:12 0.00% kdeinit4 2040 ankor 6 20 0 179M 37596K select 0:12 0.00% knotify4 2095 ankor 7 39 19 77916K 43616K uwait 0:07 0.00% virtuoso-t 2034 ankor 3 52 0 136M 44144K uwait 0:05 0.00% kwin 2063 ankor 12 39 19 118M 37412K uwait 0:04 0.00% nepomukservicestub 24373 root 1 34 0 40448K 27172K wait 0:04 0.00% ruby18 32542 ankor 5 20 0 168M 70748K select 0:03 0.00% soffice.bin 2110 ankor 3 20 0 88356K 36400K kqread 0:03 0.00% kaffeine Такое впечатление, что ничего не запускал, реагирует мгновенно и ничего не тормозит, звук не хрюкает. ULE c этим патчем работает лучше BFS. P.S. Если в ULE примут зти изменения, то в BFS смысла не вижу.

Автор:	fidaj [ Пт 04 ноя, 2011 4:59 pm ]
Заголовок сообщения:
уважаемые голосующие, таки соберитесь духом и напишите (если еще не написали) то что я просил http://www.bsdportal.ru/viewtopic.php?p=149778#149778 кратко и локанично... мне нужно набрать хоть какую-то статистику по типам процессоров... спасибо!

Страница 1 из 1	Часовой пояс: UTC + 4 часа
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/

Автор:	fidaj [ Пт 04 ноя, 2011 4:55 pm ]
Заголовок сообщения:
ankor писал(а): ULE c этим патчем работает лучше BFS. P.S. Если в ULE примут зти изменения, то в BFS смысла не вижу. "не все так просто в датском королевстве"(c)... BFS - для меня был как запасной вариант... в ULE есть проблемы с определением топологии процессоров в SMP системах, от сюда - неправильная ребалансировка - которую я по сути отсрочил, переставив участок в коде... было бы не плохо авторам ULE решить проблему в принципе, а не костыли долеплевать... надеюсь что затронутая тема в переписке к чему-то толковому приведет... и устранят именно корень проблемы...

Автор:	fidaj [ Сб 05 ноя, 2011 10:15 pm ]
Заголовок сообщения:
по поводу функции random - все стало ясно...она берется не из stdlib а из /sys/libkern/random.c что, впрчем, практически то же самое что и /usr/src/lib/libc/stdlib/rand.c и выполняется допустимо быстро...