Kernel Omnislash (Unofficial) - Aprendendo a voar sem segredos!!!

[py8elo]

Caros,
desculpem o off topic mas é apenas para avisa-los da dica que postei no tópico "Guia geral NVIDIA para Ubuntu 10.04/10.10 "...
Aí está meu caro Riven!!! Como havia lhe prometido, postei em    http://ubuntuforum-pt.org/index.php/topic,69789.240.html
uma dica que acho deveria tambem estar aqui pois diz respeito ao kernel...
Dê uma olhada e depois me comente sobre suas impressões...

[]'s,

Silva.

PY8ELO

No GCC 4.5 talvez compense marcar o C2D. Segundo o HQ as instruções que vem no C2D são muito novas e potentes, com o GCC 4.5 ele sabe lhe dar melhor com essas instruções.

Nos novos Sandy Bridge da Intel e Bulldozer da AMD, as instruções AVX foram introduzidas no GCC 4.4 e no kernel linux desde o 2.6.30
Não que isso venha ao caso, mas é interessante saber que já estão disponíveis BEM antes de sairem os processadores.

Com certeza!! A complexidade do código (e a qualidade) é o que atrapalha a performance.

Quando escolhemos um processador diferente no menu config estamos praticamente falando para ele beneficiar determinado processador.

Porém as vezes o feitiço vira contra o feiticeiro... e esse benefício não surge.

O 4.5 está melhor que o 4.4 nesse ponto, mas utilizando um processador antigo no meuconfig vc consegue bons benefícios!!

No meu K8 se eu utilizar K8 eu veja uma perda da performance o que não ocorre se eu utilizar PentiumII!! (mas claro isso é comigo)... Outros processadores farão diferente e outros K8 superiores possivelmente...

Obrigado Gunss pelo comentário!!

Não sei se perceberam... Ultrapassamos 3000 respostas, 3 anos de tópico, mais de 250 mil visitas e falamos sobre KERNEL voltado ao Ubuntu

Vcs fazem esse tópico ser divertido!! Meus parabéns a todos pela ajuda!!

Obrigado a todos!!

Hqx

[galactus]

Senhores, estou num mato sem cachorro! 

Como várias cabeças pensam mais e melhor do que uma, vou colocar aqui o que descobri até o momento sobre a questão do motivo de se colocar P4 na compilação do kernel ser melhor que Core2! Se o HQ achar que foi "fuga ao tema" eu apago a "redação" que vem a seguir!

Vocês devem ter lido que eu mudei para o Kubuntu 10.10, daí achei que ele poderia usar o GCC 4.5.1, mudei par ao GCC 4.5.1 e coloquei para compilar a arquitetura do processador Core2 para o i7 e Atom para o Atom! Tudo bonitnho como manda o figurino da documentação do GCC quanto a arquitetura dos processadores! Vejam: http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options

Apesar de ser para o 4.5.2 essa parte da documentação não mudou nada em relação ao 4.5.1! De qualquer maneira, o resultado da compilação, em comparação quando uso P4 foi horrível com o i7 e lastimável com o Atom!

Pois bem, a coisa começa a fazer água exatamente aí, na documentação do GCC, quer dizer, não é bem assim, mas depois vocês vão entender! Segundo ela, na teoria, deveríamos ter melhor desempenho ao se colocar a arquitetura correta do processador na hora de compilar! A coisa é tão séria que desde a versão 4.3 (se não estou enganado) existe uma opção de "native" se você não souber a arquitetura correta do seu processador, com essa opção ele mesmo verifica a arquitetura do procecessador e depois faz tudo o que deve! Uma verdadeira mão na roda! Mesmo assim eles não removeram a opção de você mesmo escolher a arquitetura do seu processador! 

Até aí tudo claro!  Está tudo lá, da documentação do GCC! Tudo muito bom, tudo muito bem, chega na hora de compilar e......

E que alguns "detalhes"  me passaram batido! Inconformado com esse fato da arquitetura do processador, fui ler a documentação do Gentoo e do Arch Linux em busca de respostas! Elas são distros feitas para serem compiladas, ao contrário do Debian/Ubuntu que são distros binárias! Eu sei, eu sei, tem o apt-build, mas não chega perto das opções que o Gentoo e Arch Linux têm de compilação! Vou ficar só na parte que nos toca dessa redação, a arquitetura do processador!

Vamos lá! O Gentoo e o Arch Linux possuem um arquivo na pasta /etc chamado make.conf!  Esse arquivo, como o nome já diz, contém as configurações de compilação da distro! Pois bem, o Debian/Ubuntu não possuem tal arquivo! É aí que o caldo começa entornar! Dentro deste arquivo você pode dar instruções específicas para o C e para o C++ na hora de compilar! Essas opções são passadas pelo  CFLAGS (para o C) e o CXXFLAGS (para o C++)!  Que usa o apt-build vai dizer que o CFLAGS está lá no apt-build.conf! Sim está, mas vamos continuando....

Aqui vou colocar como exemplo, um pequeno pedaço do make.conf do Gentoo:

CFLAGS="-march=athlon64 -O2 -pipe"
CXXFLAGS="${CFLAGS}"

Como podem ver, o CXXFLAGS nada mais é do que uma repetição do CFLAGS, ou seja, o que você colocar no CFLAGS, vai valer para o CXXFLAGS em relação as opções de otimização do GCC! Você ainda pode escolher colocar opções diferentes, mas isso é outro assunto!
Quem já olhou o arquivo do apt-build.conf viu que o padrão, se você não mudar nada, o CFLAGS usa a opção "mtune"  ao invés da "march" do Gentoo! E isso não é de graça! E é aí onde está o "problema"! Vou explicar melhor!

Ao utilizar a opção "mtune" implica que o código a ser compilado vai ser direcionado para otimizações da arquitetura do processador escolhido! Prestaram atenção no negrito anterior?
Tá, quando você usa a opção "march" ele gera instruções específicas para o tipo de processador selecionado!  Prestaram atenção em mais esse negrito né?

Por questões de compatibilidade e segurança, a documentação do GCC chama sua atenção quanto a isso também,  ao se usar o "mtune" vai fazer com que ele otimize o código para o processador, mas ele não usa as otimizações das instruções do processador! Ao se utilizar a opção "march", ele usa as otimizações das instruções do processador! E mais, ao se usar a opção "march" implica em dizer que o mtune vai seguir o "march", mas o contrário não é verdadeiro!
Embolou o meio de campo?
Fica fácil entender com um exemplo!

Se eu colocar mtune = core2, quer dizer que o código a ser compilado vai usar otimizações para o Core2, mas por compatibilidade e segurança ele não vai usar instruções específicas, vai usar instruções genéricas nas instruções! Aí vai depender do desenvolvedor, ele pode colocar a i386 se quiser nas intruções, mas ao que tudo indica, eles usam a nocona (que foi o primeiro pentium 4 com instruções 64bits - lembre-se, eu uso 64bits!). A nocona possui: Pentium4 com extensões 64-bit , MMX, SSE, SSE2 e SSE3! 

Se eu usar march = Core2, quer dizer que ele vai usar as instruções específicas do Core2 ( extensões 64-bit, MMX, SSE, SSE2, SSE3 e SSSE3), ou seja, se o seu processador não suportar tais instruções, o kernel não sobe!!! Ao usar o march = Core2 implica em dizer que o mtune também será Core2! Passaram o cartão agora?

mtune = código otimizado, sem instruções do processador otimizadas!
march = código e instruções do processador otimizadas de acordo com a arquitetura do processador selecionada!

Eu só tive essa luz no fim do túnel porque eu achei um fórum de programadores em C e um Canadense deu uma explicação matadora que eu não tinha lido em canto nenhum ainda!

Leiam o que o cyberfish diz:

mtune=... does NOT affect the instruction sets used, or machines the executable is run on.

For that (eg, enabling SSE), you'll need march=....

If you do march=core2 for example (on a new GCC), it will use all the instruction sets available to Core 2 CPUs. march=x also sets mtune=x. The executable won't run on older CPUs.

If you ONLY use mtune=core2, it will generate code that runs the best on a Core 2, but will still only use instructions available to all x86 CPUs (eg, no SSE), hence it will still run on old CPUs, just a little slower.

As a real world example, I think a few years ago some Linux distribution decides to use -march=pentium3 -mtune=pentium4, or something like that. That means, the code is guaranteed to run on a P3, but optimized for a P4, since they predict most people will be running for a P4.

If you don't use any flag, GCC will assume -march=i386 (lowest x86).

If you want GCC to use all instruction sets on your CPU, and optimize for your CPU (because, for example, the code will only be run on your machine), you can do -march=native (which also sets mtune=native). Only available in newer GCC (it was introduced in 4.3 or 4.4 I THINK).

-m32 and -m64 are only for generating 32-bit code on a 64-bit machine, or generating 64-bit code on a 32-bit machine, respectively. GCC defaults to 32-bit on 32-bit, and 64-bit on 64-bit.

O tópico é este aqui: http://cboard.cprogramming.com/c-programming/127502-%5Bgcc%5D-compiling-generic-x86-architecture-2.html

E quanto ao kernel? Tudo indica que ao usar o menuconfig estamos alterando apenas o mtune e não o march!!!! Pois o sistema já foi construído! É uma distro binária! Com o gentoo e o arch linux não, o "normal" deles é você construir o sistema inteiro! Eu estou dizendo tudo indica porque não acho documentação nenhuma e ninguém que saiba responder sobre isso! Estou deduzindo! Ao usar o P4 no processador, casa com a compilação do sistema daí o sistema fica muito mais rápido!

O mais perto que achei para alterar foi o makefile que vem com o kernel vanilla! No 2.6.34 está logo no início:

HOSTCC       = gcc
HOSTCXX      = g++
HOSTCFLAGS   = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer
HOSTCXXFLAGS = -O2

Tem um outro doido varrido do Fórum gringo que diz que mexeu aí e deu certo!

Vejam aqui: http://ubuntuforums.org/showthread.php?t=1579505

Eu ainda não testei!

E agora pessoal?  O que acham? Eu acho que o Canadense tem razão e que o camarada do fórum gringo chutou! Beta testers para essa possível solução? 

[MSXManiac]

Só posso dizer uma coisa Galactus...

Fruta Que Partiu!!!

Mas tu é sóóóóóóóóóóóóóda hein cara!!!

Alô HQX!

Te cuida!

Daqui a pouco a gente vai ter um kernel Bubble Bee, rsrsrsrsrsrsrsrsrs!!!

Cara, meus sinceros parabéns!!!

Como eu sou noob, só com receita de bolo prá testar! Mas aí seria demais pedir um tuto, se bem que por outro lado seria interessante vc ter um roteiro passo a passo para todos tomarem conhecimento e eventualmente vc alterar em função de sugestões, descobertas e aprimoramentos!

Fico feliz, muito feliz e imagino a tua satisfação! Algo parecido com a que tive a milênios quando pela primeira vez desassemblei um joguim que não funfava e sem saber quase nada de mnemonicos Z80 matei a charada e rodei o bendito joguim! Isso no saudoso MSX e em fita cassete, tem noção?

[MSXManiac]

A propósito, sei que não tem muito a ver mas já tendo, prá quem usa kubuntu mas não gosta do KDE 4 pq gasta muita memória, o negócio é voltar a usar o KDE 3!
E se ainda assim ficar pesado, dá prá usar o OpenBox no lugar do KWin!

Informações podem ser obtidas aqui ( https://wiki.kubuntu.org/Kubuntu/Kde3/Maverick ) e aqui ( http://apt.pearsoncomputing.net/install.html )

[MSXManiac]

Estou neste exato momento compilando com os patch's
http://liquorix.net/sources/patches/bfq-37/0002-bfq_iosched-block-add-cgroups-kconfig-and-build-bits-for-BFQ-v1-2.6.37.patch
http://liquorix.net/sources/patches/bfq-37/0001-bfq_iosched-block-prepare_IO_context_code-v1-2.6.37.patch
http://liquorix.net/sources/patches/bfq-37/0003-bfq_iosched-block-introduce_BFQ-v1-2.6.37.patch

e

http://ck.kolivas.org/patches/bfs/test/bfs363-group_uids.patch
http://ck.kolivas.org/patches/bfs/test/2.6.37-rc8-sched-bfs-363.patch

Configurações
Com 1000Mhz, Low Latency Desktop e Performance.

Vamos ver como vai ficar.

Há e claro com o GCC 4.5 do tutorial do Galactus.(parabéns pelo tuto e pelo atom super, hiper, mega, blaster, vitaminado)

Olha Andreson, eu testei e não notei nada de diferente! Isso comparando com o último kernel disponível no repositório do maverick, já que uso o Linux Mint 10 64 bits!

Também testei o patch das 4 linhas e só vi piorar o tempo de boot e o tempo entre o login e a tela estar pronta. Abrir janelas do nautilus acelerou bastante, mas no chrome por exemplo o refresh das paginas ficou bem mais lento!

também testei um kernel já com o patch das 200 linhas e não notei nada de assim tão diferente!

Deve ser pq faço uso não muito pesado!

[Gunss]

vou ler sobre o assunto galactus. Vou ser um beta tester certeza!!!

To cavucando o .config procurando algo útil

[Hqxriven]

Alô HQX!

Te cuida!

Daqui a pouco a gente vai ter um kernel Bubble Bee, rsrsrsrsrsrsrsrsrs!!!

Sinceramente isso vai ser bom!! 

Esse tópico foi criado com esse objetivo de ajudar as pessoas, para que os "segredos" viessem a público em uma linguagem mais popular e mais fácil de digerir. É por isso que nele tem tanta discussão...

Cara compilar kernel acaba sendo um terapia e também e até um desafio (tipo o dos caras que conseguem fazer um bom overclock e ganham desempenho... porém aqui não tem os perigos do overclock)

Muitas vezes já aprendi muito com os testes que fiz junto com os usuários ou a análise deles (poxa o galactus por exemplo tem uma visão extremamente detalhista de muita coisa que acontece quando ele compila... um relato que ele me passava me possibilitava dar um salto na resolução de bugs ou melhoria do processo.

Quem acompanhou o omnislash 1.4.4 viu o lançamento dos anteriores e as análises do galactus (sem contar os testes que fiz com o dobrado, gunss, gatohumano, teseu, etc... acho que a maioria deles lembra do bate papo no gtalk) e vou anotando os dados e refinando o processo! (e é por isso que o omnislash é patch com lançamento mais lento...)

Eu ainda tenho que mostrar em detalhes como eu faço tudo, para a galera ter noção do processo para entender como eu faço até chegar ao produto final bem estável. (Isso daria um tutorial gigante...)
------------

@PY8ELO

Vou dar uma olhada depois pode deixar!!

-------------------

Vou resumir o post do galactus para a galera entender.

Compilamos sempre com mtune que foi usado na compilação do gcc e das bibliotecas da distro e quando compilamos o kernel continuamos usando o mtune e beneficiamos determinado processador (como falei no post anterior) esse código genérico acrescentado dependendo do gcc gera um kernel com performance piorada pois não se trata de uma compilação específica para o nosso processador utilizando toda a capacidade do mesmo.

Usar um processador mais antigo que o nosso evita que sejam passadas determinadas instruções genéricas (para ser bonzinho eu diria capada) para o nosso processador e que ele tenha problema de performance ao utilizar elas (por isso que eu teimo em P2 no omnislash ele quase sempre está "perto" do mtune normal da distro).

O march seria o ideal mas nessa área o post do galactus já é o suficiente (acho que assim todos entendem)

É por isso que eu foquei em outras áreas no omnislash pq sabia que ia demorar para descobrir algo "modo ubuntu" para fazer...

-------------
Continuem que estou gostando!!

Hqx

[Gunss]

@Hqx então uma solução mais "rápida" seria mudar para o gentoo ou arch. Pq modificar o jeito ubuntu parece ser bem complicado, tendo que mexer nas libs do sistema e talvez até alterando o GCC, não faço a menor idéia.


ps: acho que esse tópico é um dos mais ricos na internet sobre o assunto para leigos/aprendizes.

[brottor]

Então... Testando a aqui compilado com o processador em pentium 2. O q eu percebi, teve uma melhora bem pequena, nada q mude muito! Melhorou na hora de carregar imagens e talz...

Mas piorou muito o consumo de bateria... to usando aqui parece q não dura 2 horas direito. em 1h já tá mais de 50%... acho q pra quem tem notebook, acho q vale a pena pegar a conf de core2duo/newer Xeon pois mesmo com o acpi em modo performance a bateria durou 3h.

1000 ou 300 Hz no escolha core2duo?? E na Pentium II?? (Só para saber)

1000mhz no core2 e no pentium tbm. Vou compilar em 300mhz hoje. Como o Gunns sugeriu.

[Hqxriven]

@Hqx então uma solução mais "rápida" seria mudar para o gentoo ou arch.

Podemos dizer que sim...

Pq modificar o jeito ubuntu parece ser bem complicado, tendo que mexer nas libs do sistema e talvez até alterando o GCC, não faço a menor idéia.

Já pegou algum pacote do swiftfox para o ubuntu?? (aqueles firefox otimizados...)

Podíamos executar eles sem problemas...

A questão toda Gunss é:

Como passar os parâmetros ao C e C++ no ubuntu para que ele compile o kernel com o march e crie o pacote de forma correta se o ubuntu não tem opções avançadas de fácil acesso como as distros que vc citou??

Existe a possibilidade sim (poderíamos até fazer uma compilação cruzada se fosse o caso) mas o modo ubuntu complica (ou esconde) muito as coisas... (vc tinha que ver o Gentoo na época do stage 1... controle elevado (ou total) de tudo)

[galactus]

Só posso dizer uma coisa Galactus...

Fruta Que Partiu!!!

Mas tu é sóóóóóóóóóóóóóda hein cara!!!

Alô HQX!

Te cuida!

Daqui a pouco a gente vai ter um kernel Bubble Bee, rsrsrsrsrsrsrsrsrs!!!

Cara, meus sinceros parabéns!!!

Como eu sou noob, só com receita de bolo prá testar! Mas aí seria demais pedir um tuto, se bem que por outro lado seria interessante vc ter um roteiro passo a passo para todos tomarem conhecimento e eventualmente vc alterar em função de sugestões, descobertas e aprimoramentos!

Fico feliz, muito feliz e imagino a tua satisfação! Algo parecido com a que tive a milênios quando pela primeira vez desassemblei um joguim que não funfava e sem saber quase nada de mnemonicos Z80 matei a charada e rodei o bendito joguim! Isso no saudoso MSX e em fita cassete, tem noção?

MSXManiac, menos meu caro, menos, quase nada! Obrigado pelos elogios, mas eu to muito, mas muito longe de desenvolver um kernel! Teria que devorar muitos planetas ainda pela frente!  

Realmente a satisfação é grande em descobrir essas coisas, mas veja só, eu só descubro, eu não crio nada! Tá tudo lá! Isso é que eu acho mais legal de tudo no software livre! Se você tiver tempo e conhecimento, está tudo lá, as listas de discussões e e-mails dos desenvolvedores são públicas! A documentação é pública! Se você quiser acompanhar  as "escrotiadas" que o Linus dá nos caras que desenvolvem o kernel, também!

E eu tenho noção do que era usar fita K7 num TK90, esperar 45 minutos para poder carregar um jogo e você ficar com chave philips regulando cabeçote de toca-fitas para não dar erro de leitura e você ter que começar tudo de novo! E a gente achava isso o máximo! Hehehehe

[galactus]

@Hqx então uma solução mais "rápida" seria mudar para o gentoo ou arch.

Podemos dizer que sim...

Pq modificar o jeito ubuntu parece ser bem complicado, tendo que mexer nas libs do sistema e talvez até alterando o GCC, não faço a menor idéia.

Já pegou algum pacote do swiftfox para o ubuntu?? (aqueles firefox otimizados...)

Podíamos executar eles sem problemas...

A questão toda Gunss é:

Como passar os parâmetros ao C e C++ no ubuntu para que ele compile o kernel com o march e crie o pacote de forma correta se o ubuntu não tem opções avançadas de fácil acesso como as distros que vc citou??

Existe a possibilidade sim (poderíamos até fazer uma compilação cruzada se fosse o caso) mas o modo ubuntu complica (ou esconde) muito as coisas... (vc tinha que ver o Gentoo na época do stage 1... controle elevado (ou total) de tudo)

Pois é Gunns e HQx, eu acho que pode complicar demais as coisas com o Ubuntu. Ele não foi feito para isso! 

É como eu disse e o HQx reforça, no Gentoo e no Arch Linux o controle é total!
Eu até tentei usar algumas opções do Gentoo na configuração do apt-build e deu pau!  Muitas vezes ele simplesmente não compila o pacote! Dá erro! Eu tive que retirar as opções do Gentoo, aí tudo voltou a funcionar corretamente!

É muito legal começar a ler documentação avançada dos programadores. Eu achei um texto sobre o makefile do kernel onde o camarada descreve os 4 diferentes tipos de relacionamentos com o makefile do kernel! São eles:
1- Os usuário que constroem o kernel! Essas pessoas utilizam comando como o "make menuconfig" ou "make"! Essas pessoas usualmente não leem ou editam qualquer linha do makefile do kernel ou dos códigos fontes!

2- Desenvolvedores normais! Estes trabalham com drivers de dispositivos, sitemas de arquivose protocolos de rede! Ele resume essas pessoas como tendo conhecimento intermediário!

3- Desenvolvedores de architetura! Estes precisam entender de todo o processo da arquitetura do software como sparc ou ia64. Eles precisam saber sobre o makefile e o kbuild do makefile!

4- Desenvolvedores  kbuild! São pessoas que trabalham criando o desenvolvimento do kernel! São os Linus Torvalds da vida!  Esses tem que entender de tudo!!!!


Portanto, quando eu falo que ainda me falta comer muito arroz com feijão (digo planetas) para poder desenvolver kernel, eu não estou mentindo!
Eu precisaria aprender programar em C e C++! E muitas outras coisinhas a mais! 

Não precisam ficar tristes, o que eu descobri também é que o mtune e o march não são os maiores responsáveis pelo desempenho do sistema ou do kernel! Essa é a parte boa! Você não vai ter o máximo desempenho, mas também não é o pior!

Tudo tem um perde e ganha, como eles não sabem em que processador você vai rodar o sistema, eles tem que se assegurar que o sistema funcione bem em uma quantidade muito grande de arquiteturas, por isso acabam optando por perder desempenho mas ganhar em compatibilidade e estabilidade ao usarem opções genéricas! O HQx está sendo bom demais em falar em "capado"! Hhauhauhauhuah

Rapaz, eu morro de rir lendo tópico de quem entende do riscado!  Tem programador que diz que o apt-build é uma farça!  E ele fala pois ele endente daquelas letrinhas que ficam passando quando você compila o sistema!

Eu acho que dentro do que o HQx se propõe, isso está ótimo!

Muito mais desempenho pode ser atingido, mas obrigaria a todos a mudar de distro e o serviço do HQx, que já é muito, mas muito grande mesmo, seria dobrado!

Só uma opinião, mas o kernel é do HQx, ele vai decidir o que fazer com ele, né?   

[MSXManiac]

[Como passar os parâmetros ao C e C++ no ubuntu para que ele compile o kernel com o march e crie o pacote de forma correta se o ubuntu não tem opções avançadas de fácil acesso como as distros que vc citou??

Eu tava dando uma passeada e achei estes link: http://stackoverflow.com/questions/1656201/how-to-prevent-gcc-from-passing-in-default-flags
http://www.linuxquestions.org/questions/linux-newbie-8/%5Bmakefile%5D-passing-parameters-to-gcc-732562/
http://ubuntuforums.org/archive/index.php/t-841783.html

E também estes aqui: http://manpages.ubuntu.com/manpages/maverick/en/man1/gcc-4.5.1.html
http://www.luxrender.net/forum/viewtopic.php?f=21&t=603

Interessante!

Pelo que li disso tudo e algo mais que não achei relevante, o problema todo é investigar (grep) onde mesmo usando o flag do march para tipo core2duo ele é revertido para tipo native ou outra coisa!
Tentei encontrar um post onde ficasse bem claro como forçar march independentemente mas ou eu não soube usar as palavras certas no google ou não tem como fazer!

Espero ter ajudado!

[Gunss]

Esse assunto me fez navegar pela pasta do kernel

Código Selecionar Expandir

cflags-$(CONFIG_MCORE2) += -march=i686 $(call tune,core2)

achei essa linha do arquivo Makefile_32.cpu

Código Selecionar Expandir

linux-2.6.36/arch/x86



@galactus, distros como arch e gentoo são tão complicadas assim de se usar?

[brottor]

Então... Testando a aqui compilado com o processador em pentium 2. O q eu percebi, teve uma melhora bem pequena, nada q mude muito! Melhorou na hora de carregar imagens e talz...

Mas piorou muito o consumo de bateria... to usando aqui parece q não dura 2 horas direito. em 1h já tá mais de 50%... acho q pra quem tem notebook, acho q vale a pena pegar a conf de core2duo/newer Xeon pois mesmo com o acpi em modo performance a bateria durou 3h.

1000 ou 300 Hz no escolha core2duo?? E na Pentium II?? (Só para saber)

1000mhz no core2 e no pentium tbm. Vou compilar em 300mhz hoje. Como o Gunns sugeriu.

compilado com 300mhz. Tá melhor, compilei como core2duo... Não testei a bateria ainda... quando testar posto.


Mas pelo menos pra carregar fotos e videos. Bem mais rapído. Acredito q deve melhorar o consumo de bateria tbm.