BSDPORTAL.RU http://bsdportal.ru/ |
|
Повышение степени интерактивности планировщика ULE http://bsdportal.ru/viewtopic.php?f=25&t=24900 |
Страница 1 из 1 |
Автор: | fidaj [ Пн 31 окт, 2011 11:48 pm ] |
Заголовок сообщения: | Повышение степени интерактивности планировщика ULE |
Если при сборке мира, ядра, портов в несколько потоков (>=2*ncpu) вас раздражает то, что система перестает мгновенно реагировать на ваши действия - то эта тема для вас. Все "прелести" интерактивности я начал замечать при переходе на 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. граждане, напишите пожалуйста, в такой форме:
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 пока полет нормальный. субъективно поведение системы стало заметно лучше. |
Автор: | 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 ] |
Заголовок сообщения: | |
граждане, напишите пожалуйста, в такой форме:
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:55 pm ] |
Заголовок сообщения: | |
ankor писал(а): ULE c этим патчем работает лучше BFS.
P.S. Если в ULE примут зти изменения, то в BFS смысла не вижу. "не все так просто в датском королевстве"(c)... BFS - для меня был как запасной вариант... в ULE есть проблемы с определением топологии процессоров в SMP системах, от сюда - неправильная ребалансировка - которую я по сути отсрочил, переставив участок в коде... было бы не плохо авторам ULE решить проблему в принципе, а не костыли долеплевать... надеюсь что затронутая тема в переписке к чему-то толковому приведет... и устранят именно корень проблемы... |
Автор: | fidaj [ Пт 04 ноя, 2011 4:59 pm ] |
Заголовок сообщения: | |
уважаемые голосующие, таки соберитесь духом и напишите (если еще не написали) то что я просил http://www.bsdportal.ru/viewtopic.php?p=149778#149778 кратко и локанично... мне нужно набрать хоть какую-то статистику по типам процессоров... спасибо! |
Автор: | fidaj [ Сб 05 ноя, 2011 10:15 pm ] |
Заголовок сообщения: | |
по поводу функции random - все стало ясно...она берется не из stdlib а из /sys/libkern/random.c что, впрчем, практически то же самое что и /usr/src/lib/libc/stdlib/rand.c и выполняется допустимо быстро... |
Страница 1 из 1 | Часовой пояс: UTC + 4 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |