gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
Preemptible kernel patches
Contribuído por npf em 19-03-02 10:33
do departamento patches
Linux ribeiro escreve "Viva,
Deixo aqui a indicação para as "preemptible kernel patches" do Robert Love.
A função destas é aumentar a percepção do tempo de resposta do lado do utilizador.
Supostamente, favorecem o acesso aos discos e hardware.
Tenho vindo a usar estas patches, com óptimos resultados. Elas também já fazem parte do kernel experimental 2.6.
Aqui fica o link: página

Abraços, Rui Ribeiro "

O defeito dos supostos "experts" de Linux | TRABALHO - precisa-se de coordenador de testes  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • ribeiro
  • página
  • Mais acerca Linux
  • Também por npf
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Pequena correcção (Pontos:2, Informativo)
    por rmps em 19-03-02 11:11 GMT (#1)
    (Utilizador Info) http://www.somewhere.ath.cx
    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."
    Re:Pequena correcção (Pontos:1)
    por ribeiro em 19-03-02 15:20 GMT (#3)
    (Utilizador Info) http://ruka12.tripod.com
    Claro que era 2.5, o 2.6 ainda nem sequer existe. Obrigado pelo reparo.
    Abraços, Rui
    --
    Spinlocks. (Pontos:2)
    por leitao em 19-03-02 11:22 GMT (#2)
    (Utilizador Info) http://linuxfreesite.com/~nunoleitao/

      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
    Re:Spinlocks. (Pontos:2, Interessante)
    por ribeiro em 19-03-02 15:31 GMT (#4)
    (Utilizador Info) http://ruka12.tripod.com
    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
    --
    Re:Spinlocks. (Pontos:0, Esclarecedor)
    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 :)
    Re:Spinlocks. (Pontos:2)
    por leitao em 20-03-02 0:33 GMT (#6)
    (Utilizador Info) http://linuxfreesite.com/~nunoleitao/
    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

    Re:Spinlocks. (Pontos:1)
    por ribeiro em 20-03-02 8:29 GMT (#10)
    (Utilizador Info) http://ruka12.tripod.com
    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.
    --
    Re:Spinlocks. (Pontos:2)
    por leitao em 20-03-02 9:18 GMT (#12)
    (Utilizador Info) http://linuxfreesite.com/~nunoleitao/
    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

    Re:Spinlocks. (Pontos:1)
    por ribeiro em 20-03-02 8:20 GMT (#9)
    (Utilizador Info) http://ruka12.tripod.com
    Ha. Tinha esquecido. Para uma pura mudança no scheduller, tens as patches do Ingo Molnar. É incrivel como se nota a diferença.
    --
    Lurk3rba1t: lkpc (Pontos:1)
    por zecapedra em 20-03-02 1:11 GMT (#7)
    (Utilizador Info)
    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.
    Re:Lurk3rba1t: lkpc (Pontos:1)
    por ribeiro em 20-03-02 9:17 GMT (#11)
    (Utilizador Info) http://ruka12.tripod.com
    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
    --

     

     

    [ Topo | FAQ | Editores | Contacto ]