| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Provavelmente um "lapsus teclae", mas decerto que te querias referir ao kernel experimental 2.5, visto que o 2.6 não existe e nunca podia ser experimental, sendo par o segundo número da versão. Esses patches foram incluídos desde a versão 2.5.4-pre6, melhorando substancialmente a resposta geral do sistema, com latências tipicamente inferiores a 1 ms.
--
"In my egoistical opinion, most people's C programs should be indented six feet downward and covered with dirt." |
| | | | | | Claro que era 2.5, o 2.6 ainda nem sequer existe. Obrigado pelo reparo.
Abraços, Rui
-- |
| | | |
Uma das razoes porque o Linux por vezes nao tem grande tempo de resposta e' porque ainda existem alguns spinlocks no kernel que levam muito tempo a serem largados. Como um processo nao pode ser "preempted" quando uma system call tem um spinlock por vezes o tempo de resposta e' longo.
Na minha opiniao seria uma melhor decisao eliminar estes spinlocks longos do que criar um hack que muda os algoritmos de scheduling...
Uma ferramenta util e':
http://oss.sgi.com/projects/lockmeter/
Just my 2 cents.
Regards,
echo '[dO%O+38%O+PO/d00]Fi22os0CC4BA64E418CE7l0xAP'|dc |
| | | | | | Aproveito já agora a dica para indicar aos aficionados de benchmarking, a seguinte pérola:
http://lbs.sourceforge.net
Entre outros benchmarks, encontram o kernel lockmetering indicado pelo Leitao.
Abraços, Rui
-- |
| | | por Anonimo Cobarde em 19-03-02 22:19 GMT (#5)
|
| mudar os algoritmos de scheduling? Nao fazes ideia do que estas a falar. O Preempt-Kernel do Rob Love ou o Lowlat do Andrew Morton (que sao duas implementacoes diferentes do mesmo esforco) nao muda absolutamente nada dos algoritmos de scheduling. Actualmente o Preempt-Kernel ja' esta' na serie 2.5.x e ha' alguns patches "paralelos" que o incluem nos 2.4.x, por exemplo a serie -mjc (esta' no kernel.org/pub/linux/kernel/people/mjc). Ha' ainda um complemente, o Lock-Break, tambem do Robert Love, que melhora ainda mais os casos de latencias superiores a 10ms. A tree -aa mantida pelo Andrea Arcangeli (kernel.org/pub/linux/kernel/people/aa/kernels)
contem algumas partes do lowlat do Andy Morton. tal como a variante -rmap do Rik van Riel (surriel.com/patches) tambem a contem, alem de um outro patch bastante prometedor, o read_latency2.
Mas, e ja' que falas nos algoritmos de scheduling, sim e' verdade que todo o scheduler esta' a ser re-escrito pelo Ingo Molnar da Redhat, o mesmo do Tux, por ex, podes encontrar os patches em people.redhat.com/mingo, correntemente ja' foram integrados na tree 2.5, tambem, bem como na tree 2.4-ac. Mas e' uma implementacao completamente independente do Preempt-Kernel, existem separadamente e nao necessitam uma da outra.
Quanto a isso de simplesmente "eliminar os spinlocks longos", claro que sim, mas depois o kernel tambem deixava de funcionar. Detalhes. Mas enfim, procura nos arquivos da LKML (marc.theaimsgroup.com tem um arquivo optimo) varias discussoes sobre BKL (big kernel locks) e derivados. Le, e' optimo como light reading.
Enfim, para mais detalhes, www.tech9.net/rml/linux, www.zipworld.com.au/~akpm/linux , e penso que a montavista tb tem varios documentos interessantes sobre o assunto. (Ou nao tivesse a implementacao original do preempt-kernel sido escrita pelo George Anziger, empregado da Montavista).
Seja como for, nao liguem aos argumentos do Viktor Yodaikinen ou la' como o raio do gajo se chama, e' um lunatico que so' quer fazer milhoes com o RTLinux e nao ve a concorrencia com bons olhos :)
|
| | | | | Quanto a isso de simplesmente "eliminar os spinlocks longos", claro que sim, mas depois o kernel tambem deixava de funcionar. Nao estou a ver como e' que deixava de funcionar. Aconcelho a leitura de um livro chamado "Solaris Internals" para veres porque e' que e' possivel e desejavel minimizares spinlocks.
echo '[dO%O+38%O+PO/d00]Fi22os0CC4BA64E418CE7l0xAP'|dc
|
| | | | Claro que não há que perder de vista que será possivel minimizar o tempo dos spinlocks, mas não elimina-los completamente.
Existem recursos e rotinas essenciais que têm de ser protegidas.
Aprecio a contribuição que o Robert Love teve nesse campo.
Como último comentário, direi que prefiro os spinlocks como estão, do que ter um SO com problemas de funcionamento.
-- |
| | | | | Solaris? Boa. como se o solaris fosse realmente um exemplo para alguem. Seguindo o teu raciocionio, diz-me entao o que esta' no Solaris que o faz um tao mau exemplo. E' que eu recentemente ainda nao encontrei ninguem que tenha experimentado correr Linux em ambientes SMP de mais de 16 processadores para ver o que acontece. Dizes que a melhor decisao seria elimina-los. Como nao ofereces nenhuma alternativa, suponho que queiras dizer chegar la' e arranca-los do codigo. Se supoes isso entao es burro. E' evidente que nao podes simplesmente fazer DD do codigo que tem os spinlocks, mas podes minimizar o tempo que o kernel passa 'a espera de spinlocks. Que de uma forma ou de outra e' o que faz com que o Linux nao seja particularmente aplicavel em ambientes RT. Regards,
echo '[dO%O+38%O+PO/d00]Fi22os0CC4BA64E418CE7l0xAP'|dc
|
| | | | Ha. Tinha esquecido. Para uma pura mudança no scheduller, tens as patches do Ingo Molnar. É incrivel como se nota a diferença.
-- |
| | | | Agora uma dum mero lurker:
As minhas experiências com o lkpc (Linux kernel Patch Collection), entre os quais inclui o 'Bobby' Love preemptible kernel patch são nada menos que recomendáveis.
Não sei como a coisa funciona sem ser em SMP. Como eu tenho duas máquinas dual-PIII 1000@1125/150 com o dito cujo, uma servidora e outra workstation, tenho simplesmente a dizer que nesta última as melhorias são verdadeiramente estonteantes. Particularmente, o Konq (KDE2.2.2@XF4.2.0) deixou de pendurar às primeiras bafuradas. Um alívio.
Apenas uma dica dum lurker.
Afinal, vejam desede de http://lkpc.sourceforge.net, estando a falar do stock-kernel 2.4.18.
|
| | | | | | Tenho mantido um olho nesse site, mas o seu status de beta tem-me mantido afastado.
Claro que existe muita gente que usa código comercial que de certeza tem qualidade inferior (hint: começa por W).
Abraços, Rui
-- |
| |
|
