Já que me perguntaram vou responder aqui:
Vc reclama muito da série 2.6.24 pq o último omnislash é baseado nela e como pode um kernel omnislash ser parte 2.6.24 e parte 2.6.25???É simples, estou atento a qualquer mudança que aconteça na árvore principal e nos repositórios de diversas distribuições.
É justamente por isso que o omnislash tem 86 patches, são os patches que diversas distribuições estão usando para acalmar a fera (o kernel 2.6.24) e dar mais performance ao mesmo.
O omnislash só é baseado na série 24 pq a 25 ainda não está compatível com muita coisa e estou usando a série 25 para corrigir a 24.
Vejamos alguns problemas da série 24:
1 - Primeiro problema (para mim de gravidade alta... ops beeem alta) - Mtrr não funciona direito!O que é mtrr??
http://en.wikipedia.org/wiki/Memory_Type_Range_RegistersAgora imagine o seu processador não trabalhando com a cache direito??? Preocupante... Dependendo do hardware sim, vc sente uma queda brutal de performance.
Olhe o que o Fedora fez
http://www.redhat.com/archives/fedora-package-announce/2008-April/msg00077.htmlBackport lots of MTRR fixes from 2.6.25Aí eu peguei e coloquei no omnislash e eles são tanto para 32 como 64 bits.
Consertado no omnislash 2.6.24.52 - Problema Dois - Sheduler não "aguenta" muitos eventos e faz com isso um por um (eita grave sô!!).
sch_htb: fix "too many events" situation
Consertado no omnislash 2.6.24.53 - Problema Três - Leak de memória no Vfs (gravidade média ao quadrado) - acredite vc está usando isso agora.Lembram-se desse comando que passei??
vm.vfs_cache_pressure = 200
Pois esse comando por padrão tem o valor 100 e controla a cache e o uso da memória e da swap e TODO mundo usa independente de colocar ele ou não.
vfs: fix data leak in nobh_write_end()
upstream commit: 5b41e74ad1b0bf7bc51765ae74e5dc564afc3e48
Current nobh_write_end() implementation ignore partial writes(copied < len)
case if page was fully mapped and simply mark page as Uptodate, which is
totally wrong because area [pos+copied, pos+len) wasn't updated explicitly in
previous write_begin call. It simply contains garbage from pagecache and
result in data leakage.
Consertado no omnislash 2.6.24.54 - Problema Quatro - Falha na alocação de dados por cpu (gravidade alta)alloc_percpu() fails to allocate percpu data
upstream commit: be852795e1c8d3829ddf3cb1ce806113611fa555
Some oprofile results obtained while using tbench on a 2x2 cpu machine were
very surprising.
For example, loopback_xmit() function was using high number of cpu cycles
to perform the statistic updates, supposed to be real cheap since they use
percpu data
pcpu_lstats = netdev_priv(dev);
lb_stats = per_cpu_ptr(pcpu_lstats, smp_processor_id());
lb_stats->packets++; /* HERE : serious contention */
lb_stats->bytes += skb->len;
struct pcpu_lstats is a small structure containing two longs. It appears
that on my 32bits platform, alloc_percpu(
allocates a single cache line,
instead of giving to each cpu a separate cache line.
Using the following patch gave me impressive boost in various benchmarks
( 6 % in tbench)
Basicamente conforme me foi explicado esse patch deixa enfim o kernel 2.6.24 trabalhar direito dando uma melhor performance aos cpus divindo melhor as tarefas entre eles e fazendo com que os mesmos trabalhem melhor com a cache. Olha só o que diz no log... que o usuário conseguiu até 6% de performance no tbench.
Consertado no omnislash 2.6.24.5E tem muito mais bugs, por enquanto vou ficar por aqui...
Desde o início a série omnislash foi feita com o objetivo de dar mais performance e correção de bugs como esses ajudam bastante, além de dar mais segurança ao usuário!!
Depois eu falo dos outros bugs...
Hqx
