Re: swap é mesmo necessário?

Em 12/11/05, Marcos Lazarini <lazarini@nics.unicamp.br> escreveu:

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.

O final da história: levando em conta esses fatores e características,
não dá pra concluir que o linux é mais rápido que o windows no HT só pq
tem mais processos rodando...

Nossa, falei muito... :-)

--
Marcos

--
To UNSUBSCRIBE, email to debian-user-portuguese-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org