DemYaN Опубликовано 15 февраля, 2010 (изменено) · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 16 февраля, 2010 (изменено) · Жалоба Как у вас выглядят правила tc filter add ..., tc class add ..., tc qdisc add ... ? Попробуйте увеличить quantum во всех дочерних классах. Также есть смысл выкачать git-репозиторий ядра, сделать diff между исходниками старой и новой версииями, и посмотреть что там поменялось по поводу HTB. Изменено 16 февраля, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LionSprings Опубликовано 16 февраля, 2010 · Жалоба кто-то с таким сталкивался?Угу. Вылечилось тюнингом ядра. Все не помню, но точно помню что поставил тиклесс. Ну и прооптимизировал создание правил в tc. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 16 февраля, 2010 · Жалоба кто-то с таким сталкивался?Угу. Вылечилось тюнингом ядра. Все не помню, но точно помню что поставил тиклесс. Ну и прооптимизировал создание правил в 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", что не успевает обработать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 17 февраля, 2010 (изменено) · Жалоба собственно больше интересует что подразумевает под собой "htb: too many events", что не успевает обработать? Вот текст по принципам работы HTB: http://luxik.cdi.cz/~devik/qos/htb/manual/theory.htm . Event, насколько я понял, возникает при перемещении пакетов из дочерней очереди в родительскую. Чтобы уменьшить число перемещений, нужно увеличивать quantum (к-во байт, которое может быть отправлено для данного класса, прежде чем шедулер перейдет к другому классу). У меня во всех правилах стояло quantum 1500, число правил было аналогичным, и проблем не наблюдалось. Однако, тот шейпер работал на старых ядрах, когда еще не было опции tickless kernel. Изменено 17 февраля, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 17 февраля, 2010 · Жалоба изменил quаntum на 3000, понаблюдаю Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TheRAV Опубликовано 8 декабря, 2010 · Жалоба изменил 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...