domingo, 25 de dezembro de 2011

FreeBSD

... oPtimizando o kernel.

O que queres? Um kernel mais leve, mais rápido, menor ou o quê? Em termos de opções de kernel, o FreeBSD é um dos melhores. Não... eu diria que ele é "O MÁXIMO". Mas tudo depende do que se quer fazer com ele. A maneira mais simples é copiar o GENERIC para um arquivo com o nome da tua máquina e começar a pensar no que mexer.

# cd /usr/src/sys/i386/conf
# cp GENERIC MEUKERNEL

Depois de alterado o arquivo MEUKERNEL, a compilação do MEUKERNEL é feita usando-se o parâmetro KERNCONF:

# cd /usr/src
# make buildkernel KERNCONF=MEUKERNEL

e instalar:

# make installkernel KERNCONF=MEUKERNEL


Supondo que saibas toda esta estória de 'make buildkernel', 'make installkernel', 'make buildworld' etc., os comentários deste artigo são mais específicos para a configuração do kernel a ser compilado. Se não sabes, melhor dar uma lida antes em: Building and Installing a Custom Kernel. [1]

Tamanho do Kernel

O tamanho do kernel depende do que ele carrega para a memória em termos de módulos. Hoje o FreeBSD é bem mais modulado mas, mesmo assim, alguns módulos acabam levando muito código inútil para o kernel, aumentando a memória utilizada (memory footprint). Em servidores, por exemplo, pode-se eliminar todos os módulos de rede wireless se eles forem todos cabeados.

# Wireless NIC cards
device          wlan            # 802.11 support
device          wlan_wep        # 802.11 WEP support
device          wlan_ccmp       # 802.11 CCMP support

etc...

Omitir a opção de sistemas de arquivo MSDOS (options  MSDOSFS) aumenta a liberação de memória, bem como eliminar os símbolos de DEBUG (makeoptions  DEBUG=-g). Só isto pode liberar cerca de 60% a 70% da memória utilizada pelo kernel.

Sim, estás pronto para compilar o kernel... mas, espere... "se voce fizer agora voce ainda leva mais uma máquina de lavar..." oops, não! Isto é marketing... nós ainda precisamos de making não de marketing.

O make usa um arquivo /etc/make.conf que, se nunca o editastes, provavelmente, ele não existe ainda. Mas tem um arquivo de configuração no /usr/local/etc/default/make.conf que pode servir de base para criares o teu. Ele serve para as opções do make e pode ser usado para otimizar o compilador para determinado tipo de CPU [2] e escolher opções (flags) de compilação.

Tipo de CPU

Permite o controle do código que é gerado especificamente para uma determinada CPU. Isto pode tornar o Kernel mais rápido e adaptado para teu tipo de arquitetura e pode ser feito usando-se a variável CPUTYPE.

CPUTYPE=<tipo>

Onde <tipo> pode ser uma CPU x86 tipo AMD (opteron, athlon-mp, athlon-xp, athlon-4, athlon-tbird, athlon, k8, k7, k6-3, k6-2 ou k5), tipo Intel (core2, core,nocona, pentium4m, pentium4, prescott, pentium3m, pentium3, pentium-m, pentium-2, pentiumpro, pentium-mmx, pentium, i486 e i386), tipo Via (c3 e c3-2), Alpha/AXP (ev67, ev6, pca56, ev56, ev5, ev45 e ev4), tipo AMD64 (opteron, athlon64, nocona, prescott, core2) e Intel64 (itanium2, itanium).

Flags de compilação:

Existem flags de compilação para a compilação de programas e aplicativos (CFLAGS) e para a compilação do kernel (COPTFALGS). Normalmente pode-se usar nível 3 (-O3) em CFLAGS e nível 2 (-O2) em COPTFLAGS. A compilação do kernel nunca deve ser feita com -O3 porque tende a produzir efeitos colaterais indesejáveis no kernel resultando em kernel panic. Normalmente, o -O3 produz um código mais veloz em detrimento do tamanho do binário gerado.

CFLAGS= -O3 -pipe -funroll-loops -ffast-math
COPTFLAGS= -O2 -pipe -funroll-loops -ffast-math

A opção -pipe permite que a passagem de códigos entre processos se de por pipe ao invés de arquivos temporários. A opção -funroll-loops desdobra os loops de número conhecido de iteratividade, permitindo maior velocidade de execução. Finalmente, a opção -ffast-math elimina as regras estritas de operações matemáticas descritas nas normas IEEE/ANSI. Esta opção deve ser evitada no caso de implementações estritas destas normas como, por exemplo, na compilação do Scilab, Octave ou das bibliotecas ATLAS e BLAS, bem como no desenvolvimento de programas que usem código GSL (Gnu Scientific Library).

Caso não queira alterar as opções do make, pode-se usar o arquivo de configuração do kernel e na linha abaixo da declaração 'machine', adicionar:

makeoptions    COPTFLAGS="-O2 -pipe -funroll-loops -ffast-math"

Outros truques (tricks):

Uma outra maneira de se limitar a memória usada pelo kernel é desabilitar o código relativo ao serviço de NFS. Se tu estás configurando uma estação ou servidor e sabes que não vais usar sistemas de arquivo remotos via NFS, podes usar a opção:

options        NFS_NOSERVER

Outra maneira de diminuir a memória usada pelo kernel é estabelecer o número máximo de dispositivos de swap. Normalmente o kernel precisa alocar uma quantidade fixa de memória para mapear a intercalação dos dispositivos de swap (operação chamada de interleave). Normalmente uso 1 para estações de trabalho e 2 para servidores.

options         NSWAPDEV=<number>

Referências:



[1] Manual do FreeBSD online: http://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html

[2] Kinsella, R. "Profiling and Debugging the FreeBSD* Kernel", Intel White Paper, Document Number: 321772-001, Intel Corp., 2009.

sexta-feira, 9 de dezembro de 2011

Virtualização

Xen, Qemu, VirtualBox, VMWare... o que usar?

Primeiramente, tudo depende do que o usuário necessita. Por exemplo, se é necessário criar máquinas virtuais para distribuição de serviços (http, smtp, ftp etc.) então o Xen é "o cara". Se for para testar a portabilidade entre diversas arquiteturas (x86, Sparc, PPC etc.) então a opção é o QEMU. Se for para testar performance em diversos SOs ou rodar outras distribuições em mesma arquitetura de processador, então o VirtualBox da Oracle pode ser a melhor opção.

Basicamente, podemos dizer que QEmu + KVM e VirtualBox são equivalentes, enquanto o Xen e VMWare ESXI têm uma outra abordagem de virtualização. O Xen é um virtualizador (hypervisor — a tradução é livre e minha) ou seja, uma camada de software que corre diretamente no hardware do computador, substituindo o sistema operacional propriamente dito.

A virtualização pode ser vista como um sistema "hospedeiro" e um sistema "cliente". O sistema hospedeiro pode disponibilizar recursos de hardware para que um virtualizador controle uma ou mais máquinas virtualizadas (Fig. 1).

Figura 1. Esquema de virtualização do VirtualBox


Os mais importantes virtualizadores de hoje são:


Xen

Usa um modelo denominado "thin hypervisor", com um executável de 2 MB; é atrelado aos service domains; e não usa drivers (os sistemas hospedeiros é que carregam módulos e drivers necessários). Em resumo é uma virtualização real do hardware.

VMware ESXI

Similar ao Xen mas contém os drivers de harware e mantém o gerenciamento de pilhas. O suporte do hardware depende dos drivers do VMware. [1]

QEMU+KVM

É diferente da virtualização do Xen ou do VMware. A virtualização é feita no kernel do sistema hospedeiro. A virtualização do hardware é feita pelo software e o processador virtualizado pode ser de qualquer arquitetura suportada (x86, PPC, ARM, MIPS, Sparc 32 e 64, Motorola M68k etc.) oferecendo maior portabilidade. O KVM é um acelerador da virtualização no kernel que permite a execução do código nativo enquanto emula o restante da máquina. O QEMU pode emular o multiprocessamento simétrico (SMP) mesmo em um hospedeiro com apenas uma CPU. [2]

VirtualBox

Desenvolvido inicialmente pela Sun MicroSystems e agora mantido pela Oracle, o VirtualBox é uma excelente escolha para a virtualização de sistemas operacionais sob uma mesma arquitetura. O modelo de virtualização é de compartilhamento do hardware do hospedeiro, rodando o software do sistema virtualizado direto na CPU. Entretanto o VirtualBox sempre monitora para evitar danos ao sistema hospedeiro. Os processadores Intel e AMD já suportam as tecnologias VT-x e AMD-v para a virtualização de hardware, permitindo ao VirtualBox a interceptação de operações potencialmente danosas.

Nota: em alguns sistemas é necessário habilitar a funcionalidade na BIOS.

VirtualBox [3], Xen [4] e KVM [5] são baseados no QEMU. O QEMU-SystemC [6] usa QEMU para simular um sistema onde os dispositivos de hardware são desenvolvidos em SystemC.

Referências:

[1] http://www.vmware.com/, The VMWare PC virtualizer.

[2] http://wiki.qemu.org/Main_Page, open source processor emulator.

[3] http://virtualbox.org/, The VirtualBox PC virtualizer.

[4] http://www.xen.org/, The Xen hypervisor.

[5] http://kvm.qumranet.com/kvmwiki/Front_Page, Kernel Based Virtual Machine (KVM).

[6] http://www.greensocs.com/projects/QEMUSystemC, QEMU-SystemC, a hardware co-simulator.