https://www.opennet.ru/openforum/vsluhforumID3/38687.html Ingo Molnar, чтобы доказать повышение эффективности работы нового планировщика задач (CFS), представил (http://kerneltrap.org/Linux/Measuring_Process_Scheduler_Performance) результаты сравнения производительности Linux ядер 2.6.23 и 2.6.22.9 (график (http://people.redhat.com/mingo/misc/sysbench.jpg)). Тестирование проводилось при помощи утилиты sysbench (http://sysbench.sourceforge.net/) совместно с СУБД MySQL 5.0.45.<br><br><br>Днем позже, Ingo опубликовал результаты (http://people.redhat.com/mingo/misc/sysbench-sched-devel.jpg), включив в сравнение три дополнительных конфигурации ядра 2.6.23 с подкорректированными параметрами планировщика.<br><br>URL: http://kerneltrap.org/Linux/Measuring_Process_Scheduler_Performance<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=12398<br> https://www.opennet.ru/openforum/vsluhforumID3/38687.html#37 Sun, 14 Oct 2007 22:00:47 GMT ИМХО<br><br>в не-RT ядре прерывания нужно обрабатывать сразу, по мере их появления.<br>За сим, любой свободный проц чудно подходит для этого.<br><br>А в ядре, где для прерываний свои очереди выполнения имеют - их можно и отложить, выпонив на одном проце. Именно на одном, видать, по кешу выгодно.<br> https://www.opennet.ru/openforum/vsluhforumID3/38687.html#35 Sun, 14 Oct 2007 21:50:52 GMT &gt;Хотя, может на VAX или на ARM get_seconds() не работает??? <br><br>Эй, мокрый куриц, а на мипс?<br> https://www.opennet.ru/openforum/vsluhforumID3/38687.html#34 Sun, 14 Oct 2007 19:02:33 GMT может кучкуются чтобы второй проц ничем не занимать?<br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/38687.html#33 Sun, 14 Oct 2007 09:22:26 GMT Vanila 2.6.23<br><br>pavel@toshka:~&gt; uname -a<br>Linux toshka 2.6.23 #3 SMP PREEMPT Thu Oct 11 21:59:37 MSD 2007 x86_64 x86_64 x86_64 GNU/Linux<br><br>pavel@toshka:~&gt; cat /proc/interrupts<br> CPU0 CPU1<br> 0: 101550 0 IO-APIC-edge timer<br> 1: 9 108 IO-APIC-edge i8042<br> 8: 1 0 IO-APIC-edge rtc<br> 9: 95 59 IO-APIC-fasteoi acpi<br> 12: 132 0 IO-APIC-edge i8042<br> 14: 2507 4513 IO-APIC-edge libata<br> 15: 178 769 IO-APIC-edge libata<br> 16: 1 4190 IO-APIC-fasteoi uhci_hcd:usb4, nvidia<br> 18: 31 801 IO-APIC-fasteoi uhci_hcd:usb3, tifm_7xx1, sdhci:slot0<br> 19: 0 0 IO-APIC-fasteoi uhci_hcd:usb2<br> 20: 9 353 IO-APIC-fasteoi eth0<br> 22: 627 0 IO-APIC-fasteoi HDA Intel<br> 23: 60 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5<br>NMI: 0 0<br>LOC: https://www.opennet.ru/openforum/vsluhforumID3/38687.html#32 Fri, 12 Oct 2007 23:48:04 GMT да расслабьтесь<br><br>системе с один запросом в единицу времени пофик производительность ЗАЧАСТУЮ<br><br><br>Интересны именно паралельные запросы.<br>Так что даже если пере Инго стоял выбор - он его сделал верно.<br> https://www.opennet.ru/openforum/vsluhforumID3/38687.html#31 Fri, 12 Oct 2007 19:25:20 GMT Не успели обругать.... как 2.6.23.1 надворе. :)<br><br>libata: sata_mv: more S/G fixes<br> <br>* corruption fix: we only want the lower 16 bits of length (0 == 64kb)<br><br>* ditto: the upper layer sets max-phys-segments to LIBATA_MAX_PRD, so we must reset it to own <br>hw-specific length.<br><br>* delete unused mv_fill_sg() return value.<br><br> https://www.opennet.ru/openforum/vsluhforumID3/38687.html#29 Fri, 12 Oct 2007 12:04:25 GMT У него есть свои недостатки.<br>Например (пока) он не возвращает память операционной системе. <br><br>Как стандартный аллокатор назначения он не годится.<br><br>Многопоточные программы, постоянно выделяющие/освобождающие память легко могут его использовать вместо стандартного. Остальные программы нечего ломать :)<br> https://www.opennet.ru/openforum/vsluhforumID3/38687.html#28 Fri, 12 Oct 2007 10:57:44 GMT блин, который раз накалываюсь на этом :)<br> https://www.opennet.ru/openforum/vsluhforumID3/38687.html#27 Fri, 12 Oct 2007 10:56:14 GMT Кроме прочего, в 2.6.23 добавились усовершенствования производительности в read ahead, reiserfs и XFS. Тоже, ИМХО, немаловажные штучки в плане быстродействия всей системы. Хотя в контексте этого теста они, конечно, не так чувствуются.<br>