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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED]
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 [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
