Re: swap é mesmo necessário?
Desculpe pessoal por causar essa confusão toda;
Primeiro meu PIV não é HT . O que ocorreu foi que coloquei mais um giga de
memória no meu PC e o kernel dele não reconheceu os 2GB , então instalei
erradamente o kernel-image-2.4.27.. .smp , que reconhece os 2GB o meu
problema foi ter instalado um kernel-image para multiprocessadores num PC
com somente uma CPU, então quando colocava doi processos para rodar ao
mesmo tempo ele colocava 99% em cada um aí a CPU esquentava e emitia um
aviso de bip e a menssagem de temperatura over na CPU, então um colega da
lista disse porque você baixou um kernel para multiprocessadores se você
só tem um, aí caiu a ficha , então voltei e baixei o mesmo kernel-image só
que para um processador e agora está tudo ok, abri o gabinete comprei 3
ventiladores XPC de 120MM e coloquei nos cabos de minha fonte de 700W e tá
funcionando legal , o único problema é a poeira.
espero ter esclarecido este episódio
obrigado.
Marcos Vinicius Lazarini
> Datacom - Tavares wrote:
>
>> On Sat, 2005-10-29 at 10:23 -0200, Marcos Lazarini wrote:
>>
>>>Datacom - Tavares wrote:
>>>
>>>>On Tue, 2005-10-11 at 23:17 -0300, Marcos Lazarini wrote:
>>>>
>>>>
>>>>>>E tem um problema, se voce habilitar na Bios o HT e usar um kernel
>>>>>> nao SMP ou um windows 98 sem suporte a SMP, o sistema ficará
>>>>>> instavel..
>>>>>
>>>>>Isso eu já nao sei não, veja os e-mails do Francisco que iniciou a
>>>>> thread - ele usava um HT com kernel 2.4 não smp. E só comecou a
>>>>> travar depois que comecou a brincar com essas coisas.
>>>>
>>>>Partindo do principio q se vc tiver 2 cores e um kernel nao SMP,
>>>> somente o core 1 serah usado, com HT o mesmo pode ocorrer, correto?
>>>> Nao aproveitando o hardware do sistema de forma plena e deixando
>>>> parte processador ocioso..
>>>
>>>Isso é instavel? Veja o que voce mesmo falou acima
>>
>>
>> Independente..
>> Pra que voce vai usar um sistema com HT configurado de maneira
>> incorreta?
>
> Veja o caso do Francisco, pois ao ligar o HT a CPU esquentou demais e
> comecou a travar!
>
>> Nao sei se eh instavel pois nunca o usei configurado incorretamente
>> para testar se fica instavel..
>
> Bom, não é o que vc mesmo disse lá no comeco.
>
>> Quando comprei a maquina a 3 anos atras (aproximadamente) li textos
>> que afirmavam que essa possibilidade existia..
>
> Aqui vc tirou o corpo da reta... :-)
>
>
> [........]
>
>>>>Exemplo: Ao carregar o windows tens bem poucas threads gerenciando
>>>> todo o ambiente grafico.
>>>>No linux, o ambiente grafico se resume a um grande conjunto de
>>>>programas, por exemplo, gerenciador de janelas, font-server, desktop,
>>>> painel, etc, etc, etc, e cada um com suas n threads.. entende agora o
>>>> q quis dizer?
>>>>
>>>>A natureza do linux eh muito mais paralelizavel do q a do windows,
>>>> portanto uma maquina com linux com HT teria um ganho bem maior em
>>>> comparacao a uma sem HT do q se compararmos a uma maquina com windows
>>>> com HT e sem HT. Fui claro agora na minha explicacao? :)
>>>
>>>Agora tá entendido o seu conceito, só não sei se há relação direta com
>>> o numero de processos (ou threads) rodando com a capacidade de
>>>paralelização como vc assume (e consequente ganho de velocidade).
>>
>> Na verdade, todo esse assunto eh bem complicado e cheio de variaveis..
>> Acho que somente no final consegui explicar o que estava querendo
>> dizer.. :)
>
> Bom, conversando com o meu personal linux guru :-), cito alguns pontos
> importantes em relação a processos e threads, só pra esclarecer:
>
> 1- um processo é uma entidade completamente independente dos demais.
> Cada processo carrega uma tonelada de tabelas, que registram todos os
> dados e passos do processo (memória alocada, registros, etc etc).
> 2- Com essas tabelas, o kernel sabe dizer, pra qquer bit alocado, qual
> processo é dono e consegue manter a independencia das coisas, de modo
> que um processo somente possa atuar na sua área de direito. Por isso
> existem segmentations faults da vida.
> 3- Toda essa verificação causa um enorme overhead pro kernel (que,
> apesar de ruim, é fundamental), que tem que ficar verificando um monte
> de coisas, carregando tabelas, etc e tal.
> 4- Por causa disso surgem uma série de inconvenientes pra fazer
> comunicação inter-processos (named pipes, sockets, etc)
>
> a- threads surgiram como processos 'economicos': threads podem
> compartilhar a maioria das tabelas que um processo possui. Vantagem:
> pouquissimo overhead, o que as deixa bem mais rápidas que processos
> inteiros.
> Desvantagem: aquela isolação perfeita entre os processos (garantida pelo
> kernel) foi por água abaixo - virou festa e uma thread pode escrever na
> memória da outra, de boa.
>
>
> Como o kernel 2.6 implementa essas coisas eu nao estou bem a par, mas
> sei que há uma diferença sim em relação aos outros SO. No caso, me
> parece que tem a ver com o copy-on-write, devido a característica do
> processo de criação de processos novos (fork) - que não vem ao caso
> agora (pq é assunto pra muitos e-mails)
>
>
> Voltando agora....
> No caso do windows, temos bem menos processos pq muitas coisas por lá
> são tratadas pelo kernel, como som e vídeo. Não há processos separados
> pra várias coisas já embutidas lá dentro. Isso pode ser até uma
> vantagem, já que
> há menos troca de contexto entre os diversos processos e vc tem mais
> controle sobre o que acontece. Obviamente, se essas partes fizerem
> cacas, vc recebe uma bela tela azul de presente... :-)
> Definitivamente, pra monoprocessado, quanto mais coisa em kernel space,
> mais rápida a maquina fica, porém os riscos de problemas sérios aumentam
> exponencialmente.
>
> Falando agora em relação a multiprocessamento, vamos falar primeiro do
> HT. o HT não é dual de verdade, ele apenas duplica as unidades de
> controle e execução internas, pra decodificar duas instruções ao mesmo
> tempo. Se elas utilizarem recursos diferentes da CPU, elas podem ser
> executadas ao mesmo tempo. Senão, entra na fila e vira uma só CPU. Na
> prática, é dificil comparar com um dual de verdade, mas o desempenho
> varia muito com a atividade e em geral é consideravelmente abaixo do
> dual.
>
> Agora sim: se você tem um processo, não é possível dividí-lo entre as
> CPUs. Dois ou mais processos, são escalonados de acordo. Nesse ponto,
> vamos pensar o que é mais rápido: 100 processos que precisam de 1s cada
> pra processar, ou 10 processos de 10s cada? E quem teve mais trabalho?
> Sem mencionar comunicação inter-processos aqui, pra nao ficar
> complicado.
>
> Aonde eu quero chegar: 'paralelizar' uma coisa sem reimplementar o
> algoritmo (pensando em aproveitar a parelização) muda pouca coisa
> (tanto no windows como no linux), pois quem vai estar trabalhando mesmo
> é o escalonador de cada um. Pelo meu ponto de vista, o ganho vai ser
> mais ou menos o mesmo em ambos os casos.
>
>
> --
> Marcos
>
>
> --
> To UNSUBSCRIBE, email to debian-user-portuguese-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
F. W. S. Lima
Departamento de Física
Centro de Ciência da Natureza
Campus Petrônio Portela
Universidade Federal do Piauí
Teresina-Piauí-Brasil
wel@ufpi.br,wel@fisica.ufc.br, wel@sobral.org
Reply to: