Опубликованы (http://www.phoronix.com/scan.php?page=article&item=linux_262...) результаты тестирования  производительности Linux ядра 2.6.28, в сравнении с версиями 2.6.25, 2.6.26 и 2.6.27. В 14 тестах различия в производительности оказались на уровне погрешности (в 5 тестах 2.6.28 продемонстрировало незначительное отставание, а в 9 - незначительное опережение конкурентов). Лишь в одном тесте скорости рендеринга изображений Sunflow, ядро 2.6.28 оказалось быстрее на 10%.

URL: http://www.phoronix.com/scan.php?page=article&item=linux_262...
Новость: http://www.opennet.me/opennews/art.shtml?num=19590

• Оценка производительности Linux ядра 2.6.28,anonymous, 01:16 , 29-Дек-08
  • Оценка производительности Linux ядра 2.6.28,Guest, 01:59 , 29-Дек-08
    • Оценка производительности Linux ядра 2.6.28,Аноним, 02:29 , 29-Дек-08
  • Оценка производительности Linux ядра 2.6.28,User294, 00:34 , 31-Дек-08
• Оценка производительности Linux ядра 2.6.28,Аноним, 02:21 , 29-Дек-08
  • Оценка производительности Linux ядра 2.6.28,Аноним, 08:58 , 29-Дек-08
    • Оценка производительности Linux ядра 2.6.28,Frank, 09:20 , 29-Дек-08
      • Оценка производительности Linux ядра 2.6.28,Nuclearcat, 12:04 , 29-Дек-08
        • Оценка производительности Linux ядра 2.6.28,pavlinux, 13:43 , 29-Дек-08
          • Оценка производительности Linux ядра 2.6.28,Nuclearcat, 13:56 , 29-Дек-08
            • Оценка производительности Linux ядра 2.6.28,pavlinux, 22:56 , 30-Дек-08
              • Оценка производительности Linux ядра 2.6.28,User294, 03:59 , 31-Дек-08
                • Оценка производительности Linux ядра 2.6.28,., 06:14 , 31-Дек-08
• Оценка производительности Linux ядра 2.6.28,Аноним, 10:11 , 29-Дек-08
  • Оценка производительности Linux ядра 2.6.28,Аноним, 12:02 , 29-Дек-08
  • Оценка производительности Linux ядра 2.6.28,наполеон, 14:04 , 29-Дек-08
    • Оценка производительности Linux ядра 2.6.28,vitek, 01:12 , 30-Дек-08

надо собирать его просто нормально!

Гыгы, ты думаешь они специально ядра по-разному собирали? А ты типа можешь правильно собрать эти ядра, так что .28 будет во всех тестах на 300% быстрее? Детский сад...

легко! Надо просто всех конкурентов .28 собрать из-под-выподверта! Тогда .28 всех обойдет :)

>надо собирать его просто нормально!

Например?Такие заявы ничто без рекомендаций.

А с чего вдруг должна меняться производительность ?
глупость какая-то.

>А с чего вдруг должна меняться производительность ?
>глупость какая-то.

Ну хотя-бы из-за GEM? ;)

>>А с чего вдруг должна меняться производительность ?
>>глупость какая-то.
>
>Ну хотя-бы из-за GEM? ;)
> we were using ... the NVIDIA 180.18 display driver

и о каком GEM тут может быть речь?

С tainted ядром их бенчмарки сильно теряют ценность.

sysctl -w kernel.tainted=1

>sysctl -w kernel.tainted=1

Суть в том, что неизвестно как вмешиваются дрова от Nvidia в производительность.
В особенности графических подсистем.
А какой-нить кривой loop - и обычных.

Qemu + gdb + MmioTrace - фсе скажет!

Уж чего-чего, а тормоза можно без кода отловить!

Изучали, вставляли пустой дривер вместо nv-kernel.o, бряки на точках входа, данные инициализации регистров.... и т.д.
В Nvidia много напихали для защиты кода: случайные адреса, куча глобальных переменных,
которые хрен отловишь - где-то инициализируются, а где действительно меняются, разбито
на мелкие функции, вплоть до тупого min/max.
Точно сказать не могём, но создаётся   впечатление, что они шифруют свой data segment
в памяти, потому что, там каша полная... И естественно, много irq_disable()/irq_enable(),..., up()/down().

>Qemu + gdb + MmioTrace - фсе скажет!

Ага, еще IDA Pro посоветуйте... а ради чего весь этот гемор?

>>Qemu + gdb + MmioTrace - фсе скажет!
>Ага, еще IDA Pro посоветуйте... а ради чего весь этот гемор?

just for lulz

>Ну хотя-бы из-за GEM? ;)

я думал GEM на карточках от интел работать должен. я тут нвидиа.

> я тут нвидиа.
>

одним наполеоном меньше ;)

>я думал GEM на карточках от интел работать должен. я тут нвидиа.
>

он должен работать с любым вариантом

кто?