Re: swap é mesmo necessário?

[Marcos Vinicius Lazarini <lazarini@nics.unicamp.br>]

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