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 писал(а):
... и безопасно ли это делать?
безопасно для чего именно... в каком смысле - не понял...