[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kernel 2.6.0 Released - Quem deve atualizar?



 Mário,
 com relação ao seu último comentário no email abaixo. No kernel 2.4.22
eu habilitei a diretiva CONFIG_SMP=y para que um segundo processador
seja habilitado, como permite a tecnologia Hyper Threading. Durante a
inicialização os dois processadores são reconhecidos, mas em um top
aparece apenas um.

 Agora a pergunta, na série 2.6 a configuração será tão simples quanto
ativar uma diretiva ou vou precisar fazer algum "mambo jambo" pra ter
isso funcionando?

 By the way... alguém já documentou ou leu alguma documentação sobre uma
migração woody-->sarge feita com sucesso?

 Agradeço antecipadamente,
  Vitor

Era uma vez, em Mon, 22 Dec 2003 09:19:43 -0200
Mario disse:

| On Fri, Dec 19, 2003 at 09:44:12PM -0200, Fabricio Cannini Flores
| wrote:> Me corrijam se estiver errado,
| > mas seria então por isso que tem gente escalando o 2.6 a 64
| > processadores por kernel?
| 
| um kernel preemptível tem um mecanismo de lock mais refinado, isto é,
| as estruturas de dados do kernel são protegidas por "lockings", de
| modo que se uma instância do kernel que estiver rodando em um
| processador for interrompida (preemptada - removida da cpu), as
| estruturas de dados que ela está utilizando não serão
| corrompidas/alteradas/deixadas_inconsistentes por outra instância do
| kernel que esteja rodando em qualquer outra cpu.
| 
| como disse o Leandro G.F.C. Dutra, isto já existia no kernel antigo, 
| mas em menor escala. no 2.6.0 este mecanismo foi refinado.
| 
| existem algumas situações que devem ser protegidos:
| - dados por CPU, estado da CPU; tb os locks têm que ser adquiridos e
|   liberados pela mesma tarefa.
| 
| a solução para a proteção de dados sob preempção é _desabilitar_ a
| preempção enquanto durar a região crítica (trecho de código onde se
| acessa variáveis compartilhadas e que pode resultar em inconsistência
| se não tiver exclusão mútua).
| 
| no 2.6.0 os lockings ficaram muito mais leves, e normalmente são por
| CPU, o que deixa as outras instâncias executando. 
| 
| além dos lockings, existem situações em que as interrupções precisam
| ser desabilitadas, e isto é feito em grande parte somente na CPU
| local, também deixando as outras instâncias executando. ainda é
| possível desabilitar as interrupções globalmente, mas estas situações
| são mais raras e são sempre desencorajadas, ou seja, nada de
| programador preguiçoso no kernel.
| 
| 
| 
| > Claro que fazem isso porque o 2.6 tem suporte a NUMA (non-uniform
| > memory access, acesso não uniforme á memória), e um agendamento de
| > processos turbinado como está o do 2.6.
| > Seria isso? 
| 
| não somente para NUMA mas tb para SMP.
| 
| referências: preempt-locking.txt, sched-coding.txt e
| cli-sti-removal.txt
| 
| 
| -- 
| Mario O.de Menezes, Ph.D.    "Many are the plans in a man's heart, but
|     IPEN-CNEN/SP                is the Lord's purpose that prevails"
| http://www.ipen.br/~mario                  Prov. 19.21
|     
| 
| 
| -- 
| To UNSUBSCRIBE, email to
| debian-user-portuguese-request@lists.debian.org with a subject of
| "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: