[DemYaN]

Linux, htb, около 4000 htb-классов.

С переходом с версии ядра 2.6.28 на 2.6.32.8 время от времени в логи начали вываливаться сообщения:

[  792.604379] htb: too many events!
[ 2777.926380] htb: too many events!
[18414.947790] htb: too many events!

кто-то с таким сталкивался?

 

кусок кода ответственного кода:

/**
* htb_do_events - make mode changes to classes at the level
*
* Scans event queue for pending events and applies them. Returns time of
* next pending event (0 for no event in pq, q->now for too many events).
* Note: Applied are events whose have cl->pq_key <= q->now.
*/
static psched_time_t htb_do_events(struct htb_sched *q, int level,
                                   unsigned long start)
{
        /* don't run for longer than 2 jiffies; 2 is used instead of
           1 to simplify things when jiffy is going to be incremented
           too soon */
        unsigned long stop_at = start + 2;
        while (time_before(jiffies, stop_at)) {
                struct htb_class *cl;
                long diff;
                struct rb_node *p = rb_first(&q->wait_pq[level]);

                if (!p)
                        return 0;

                cl = rb_entry(p, struct htb_class, pq_node);
                if (cl->pq_key > q->now)
                        return cl->pq_key;

                htb_safe_rb_erase(p, q->wait_pq + level);
                diff = psched_tdiff_bounded(q->now, cl->t_c, cl->mbuffer);
                htb_change_class_mode(q, cl, &diff);
                if (cl->cmode != HTB_CAN_SEND)
                        htb_add_to_wait_tree(q, cl, diff);
        }

        /* too much load - let's continue after a break for scheduling */
        if (!(q->warned & HTB_WARN_TOOMANYEVENTS)) {
                printk(KERN_WARNING "htb: too many events!\n");
                q->warned |= HTB_WARN_TOOMANYEVENTS;
        }

        return q->now;
}

Изменено 16 февраля, 2010 пользователем DemYaN

[photon]

Как у вас выглядят правила tc filter add ..., tc class add ..., tc qdisc add ... ? Попробуйте увеличить quantum во всех дочерних классах. Также есть смысл выкачать git-репозиторий ядра, сделать diff между исходниками старой и новой версииями, и посмотреть что там поменялось по поводу HTB.

Изменено 16 февраля, 2010 пользователем photon

[LionSprings]

кто-то с таким сталкивался?

Угу. Вылечилось тюнингом ядра. Все не помню, но точно помню что поставил тиклесс. Ну и прооптимизировал создание правил в tc.

 

[DemYaN]

кто-то с таким сталкивался?

Угу. Вылечилось тюнингом ядра. Все не помню, но точно помню что поставил тиклесс. Ну и прооптимизировал создание правил в tc.

1 система no_hz, hrtimers

2 3897 фильтров u32 разбросаны по последнему октету ip-адреса в 256 хеш-таблиц

3 карты вход/выход - i82573, поэтому загружены только 2 ядра, загрузка каждого ядра по softirq в ЧНН под 80%, львиную долю сжирает u32

 

perf-top:

              286.00 - 13.7% : u32_classify     [cls_u32]
              187.00 -  9.0% : e1000_clean      [e1000e]
              178.00 -  8.5% : ipt_do_table     [ip_tables]
              117.00 -  5.6% : e1000_intr_msi   [e1000e]
               70.00 -  3.4% : ip_route_input
               58.00 -  2.8% : htb_dequeue      [sch_htb]
               40.00 -  1.9% : _spin_lock
               34.00 -  1.6% : read_tsc
               31.00 -  1.5% : e1000_clean_rx_irq       [e1000e]
               29.00 -  1.4% : htb_enqueue      [sch_htb]
               27.00 -  1.3% : nf_iterate
               26.00 -  1.2% : iphash_ktest     [ip_set_iphash]
               25.00 -  1.2% : __nf_conntrack_find      [nf_conntrack]
               25.00 -  1.2% : _spin_lock_irqsave
               23.00 -  1.1% : copy_to_user

 

собственно больше интересует что подразумевает под собой "htb: too many events", что не успевает обработать?

 

[photon]

собственно больше интересует что подразумевает под собой "htb: too many events", что не успевает обработать?

Вот текст по принципам работы HTB: http://luxik.cdi.cz/~devik/qos/htb/manual/theory.htm . Event, насколько я понял, возникает при перемещении пакетов из дочерней очереди в родительскую. Чтобы уменьшить число перемещений, нужно увеличивать quantum (к-во байт, которое может быть отправлено для данного класса, прежде чем шедулер перейдет к другому классу). У меня во всех правилах стояло quantum 1500, число правил было аналогичным, и проблем не наблюдалось. Однако, тот шейпер работал на старых ядрах, когда еще не было опции tickless kernel.

Изменено 17 февраля, 2010 пользователем photon

[DemYaN]

изменил quаntum на 3000, понаблюдаю

[TheRAV]

изменил quаntum на 3000, понаблюдаю

Помогло ли?

То же самое имею.

$ uname -a

Linux R7 2.6.34-gentoo-r12 #1 SMP Mon Dec 6 16:56:01 EET 2010 x86_64 Intel® Core i7 CPU 920 @ 2.67GHz GenuineIntel GNU/Linux