Mesmo o bug das placas de rede e1000e não tendo sido corrigido, o kernel conta com uma série de fixes que impedem que seja causado algum dano ao hardware.
Anyway, vamos dar uma olhada no que
- Lockless page cache:
A "page cache" é o local onde o kernel deixa em memória uma cópia de um arquivo em disco, para evitar I/O.
Existia um lock para evitar problemas em sistemas com múltiplos CPUs, logo quando diferentes CPUs tentavam acessar arquivos diferentes não tínhamos problemas, porém quando dois CPUs tentavam acessar um mesmo arquivo (uma shared library do sistema por exemplo), somente um poderia ler a cada vez. Agora, graças a algumas novas regras que definem como a "page cache" é utilizada e pela utilização de RCU, será possível ler a "page cache" sem ser necessário fazer o lock.
Porém esta melhora só será observada em sistemas com muitas CPUs.
Links relacionados:
LWN: Toward better direct I/O scalability (http://lwn.net/Articles/275808/)
LWN: The lockless page cache (http://lwn.net/Articles/291826/)
WIKI: RCU (http://en.wikipedia.org/wiki/Read-copy-update)
- Lockless get_user_pages():
A função get_user_pages() é utilizada em operações de I/O diretas para travar o espaço de memória que será transferido.
Entretanto é uma função complexa e que utilizada semáforos e locks, que causavam problemas de escalabilidade quando se tinha diversos processos utilizando está função em uma mesma área de memória.
No kernel 2.6.27 uma nova função get_user_pages_fast() foi introduzida, a qual faz a mesma operação que a get_user_pages() porem determinadas operações foram simplificadas de modo que não é necessário obter o semáforo nem o lock. Alguns testes registraram uma melhora de 10% em um sistema quad-core com um banco de dados IBM DB2 com um workload OLTP.
Links relacionados:
WIKI: OLPT (http://en.wikipedia.org/wiki/Online_transaction_processing)
- Ext4: Delayed Allocation:
Neste versão foi adicionado ao sistema de arquivos ext4, um dos mais importantes recursos planejados a "Delayed Allocation" (alocação tardia, conhecida também como Allocate-on-flush).
Este recurso não altera a estrutura do disco, mas melhora a velocidade em diversas situações.
Uma breve explicação de como funciona: Quando uma aplicação quer escrever algo em disco, os dados não são escritos imediatamente, mas são colocados em uma área de memória RAM por algum tempo. Mas independente de ser escrita ou não imediatamente, o sistema de arquivos aloca as estruturas necessárias em disco na hora. A alocação tardia consiste em não alocar estas estruturas para os dados que estão cacheados na RAM, ela apenas atualiza a estrutura que indica quanto espaço livre em disco ainda temos, quando é feita uma operação de escrita. Os blocos e estruturas no disco são somente alocados quando os dados são realmente escritos.
Esta técnica é utilizada por outros sistemas de arquivos como o XFS, Btrfs, ZFS e o Reiser4 e apresenta um notável ganho de velocidade e também resulta em decisões melhores para a alocação dos blocos, pois neste momento o sistema de arquivos ja conhece tudo que deverá escrever.
Links relacionados:
WIKI: EXT4 (http://en.wikipedia.org/wiki/Ext4)
WIKI: Allocate-on-flush (http://en.wikipedia.org/wiki/Allocate-on-flush)
WIKI: Sistema de Arquivos (http://en.wikipedia.org/wiki/Filesystem)
WIKI: XFS (http://en.wikipedia.org/wiki/XFS)
WIKI: Btrfs (http://en.wikipedia.org/wiki/Btrfs)
WIKI: ZFS (http://en.wikipedia.org/wiki/ZFS)
WIKI: Reiser4 (http://en.wikipedia.org/wiki/Reiser4)
- Kexec jump: kexec/kdump based hibernation:
O Kexec é um recurso do Linux que permite que carregar um kernel na memória e executa-lo, ou seja permitindo que se "reinicie em um novo kernel", sem reiniciar o PC.
Assim era implementado o Kdump, um sistema de dump para quando o kernel travava: Um kernel estável/seguro (que se tinha certeza que iria funcionar) era carregado na memória assim que o sistema iniciasse e caso acontecesse do kernel principal do sistema travar o "oops code" executava o Kexec, que passava para o kernel estável/seguro, que então fazia um dump da memória.
Esta implementação foi melhorada no kernel 2.6.27 agora podendo ser usada para fazer a hibernação do sistema, ou seja, o sistema iria chamar o Kexec para executar um segundo kernel que faria o dump da memória em disco e depois desligaria o computador. Quando a máquina fosse religada, o initrd poderia carregar os dados e restaura-los.
Esta implementação de hibernação não substitui as outras, apenas é mais uma alternativa que tem algumas vantagens como não depender da ACPI. Porém por enquanto só funciona em sistemas X86-32.
Links relacionados:
LWN: Yet another approach to software suspend (http://lwn.net/Articles/242107/)
WIKI: Kexec (http://en.wikipedia.org/wiki/Kexec)
WEB: Kdump (http://lse.sourceforge.net/kdump/)
WIKI: Hibernação (http://en.wikipedia.org/wiki/Hibernate_(OS_feature))
WIKI: ACPI (http://en.wikipedia.org/wiki/ACPI)
WIKI: X86-32 (http://en.wikipedia.org/wiki/X86-32)
WIKI: initrd (http://en.wikipedia.org/wiki/Initrd)
- UBIFS:
UBIFS é um novo sistema de arquivos para dispositivos flash, desenvolvido pela Nokia com a Universidade de Szeged.
O UBIFS é bem diferente dos outros sistemas de arquivos tradicionais, ele não trabalha com dispositivos baseados em blocos, mas somente em dispositivos flashs "puros", manipulados pelo subsistema MTD no Linux.
Logo o UBIFS não funciona com o que muitas pessoas consideram dispositivos flashs como HDs flash, cartões SD, pen-drives/USB-sticks, etc, por causa que estes dispositivos utilizam uma camada de emulação para dispositivos de blocos, chamada FTL (Flash Translation Layer) que fazem com que estes dispositivos pareçam ser organizados através de blocos como.
O UBIFS foi feito para os dispositivos que não utilizam o FTL e que são manipulados pelo subsistema MTD e apresentam-se para o userspace como dispositivos MTD.
O UBIFS opera em cima de volumes UBI (Unsorted Block Images). (O UBI é uma camada como o LVM, que entrou no kernel na versão 2.6.22, que este sim opera em cima de dispositivos MTD). O UBIFS oferece diversas vantagens sobre o JFFS2: tempos de montagem mais rápidos e escalonáveis, tolerância a hard-reboots (conhecidos como dedoffs) pois é um sistema com journaling, suporte a write-back e a compressão "on-the-fly".
Links relacionados:
LWN: UBIFS (http://lwn.net/Articles/276025/)
WIKI: MTD (http://en.wikipedia.org/wiki/Memory_Technology_Device)
WIKI: FTL (http://en.wikipedia.org/wiki/Flash_Translation_Layer#Flash_file_systems)
WIKI: Userspace (http://en.wikipedia.org/wiki/Userspace)
WIKI: JFFS2 (http://en.wikipedia.org/wiki/JFFS2)
WIKI: Journaling (http://en.wikipedia.org/wiki/Journaling_file_system)
WEB: UBIFS FAQ (http://www.linux-mtd.infradead.org/faq/ubifs.html)
WEB: UBIFS DOCs (http://www.linux-mtd.infradead.org/doc/ubifs.html)
- OMFS:
OMFS significa "Sonicblue Optimized MPEG File System support" e é um sistema de arquivos proprietário utilizado pelo player de música Rio Karma e o ReplayTV DVR. Desconsiderando o nome, este sistema de arquivos não é mais eficiente que um sistema de arquivos padrão quando se trata de arquivos MPEG.
Links relacionados:
LWN: OMFS (http://lwn.net/Articles/278028/)
- Block layer data integrity support
Sistemas de arquivos modernos contam com o recurso de checksum de dados e meta-dados para proteger-se contra dados corrompidos. Porém a checagem é feita em tempo de leitura, que pode acontecer meses depois dos dados terem sido escritos e neste ponto os dados que a aplicação tentou escrever, provavelmente ja estão perdidos. A solução é verificar que o que esta sendo gravado em disco é o que realmente espera-se.
Recentes adições aos protocolos da família SCSI (SBC Data Integrity Field, SCC protection proposal) e ao SATA/T13 (External Path Protection) tentam melhorar esta situação adicionando suporte a adição de meta-dados de integridade em um I/O. Estes meta-dados de integridade contém um checksum de cada setor e um contador incremental que garante que os dados serão escritos na ordem certa.
Links relacionados:
LWN: Block layer: integrity checking and lots of partitions (http://lwn.net/Articles/290141/)
WIKI: Checksum (http://en.wikipedia.org/wiki/Checksum)
WIKI: SCSI (http://en.wikipedia.org/wiki/SCSI)
WIKI: SATA (http://en.wikipedia.org/wiki/SATA)
- Multiqueue networking:
Uma das principais estruturas de dados do subsistema de redes é a fila associada a cada dispositivo para a transmissão de dados.
Este métodos funcionou muito bem por anos, porém vem encontrando uma barreira ultimamente: Não funciona bem para dispositivos com múltiplas filas.
E dispositivos assim estão se tornando mais comuns, principalmente na área de redes sem fio, como por exemplo os dispositivos que implementam o Wireless Multimedia Extensions que podem ter 4 "classes de serviços", onde alguns serviços podem ter mais prioridades que outros.
O kernel 2.6.27 agora tem suporte a estes dispositivos.
Links relacionados:
LWN : Multiqueue networking (http://lwn.net/Articles/289137/)
WIKI: Wireless Multimedia Extensions (http://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions)
- ftrace:
O ftracer é um simples tracer de funções que nasceu na árvore -rt (Real Time) de desenvolvimento.
Ele utiliza um recurso do compilador para inserir uma pequena instrução NOP de 5 bytes no início de cada função do kernel. Então estas instruções NOP são modificadas em tempo de execução em uma chamada ao tracer quando a opção de tracing está habilitada pelo administrador do sistema, caso esta não esteja o overhead encontrado é muito pequeno e desprezível até em micro-benchmarks.
Apesar do ftrace trabalhar com funções ele inclui um sistema de plugins que permite outros tipos de tracing.
Links relacionados:
WIKI: Real Time (http://en.wikipedia.org/wiki/Real-time_operating_system)
WIKI: NOP (http://en.wikipedia.org/wiki/NOP)
WIKI: Overhead (http://en.wikipedia.org/wiki/Computational_overhead)
WIKI: Benchmark (http://en.wikipedia.org/wiki/Benchmark_(computing))
- Mmiotrace:
Mmiotrace é uma ferramenta para capturar acessos MMIO (Memory Mapped IO) no kernel Como o MMIO é utilizado por drivers, esta ferramenta pode ser utilizada para debugging e engenharia reversa de drivers binários.
Links relacionados:
LWN: Tracing memory-mapped I/O operations (http://lwn.net/Articles/270939/)
WIKI: MMIO (http://en.wikipedia.org/wiki/IO_port)
- External firmware:
O Firmware normalmente é compilado junto com o drivers, porém por algumas questões legais (de licenciamento na maioria), a distribuição de alguns firmwares não é permitido por algumas empresas e alguns drivers tem suportado que um firmware externo seja carregado.
Porém mesmo que um firmware, que possa ser legalmente redistribuído, mas não atende as diretivas do "software livre", então algumas pessoas acham que isto quebra a GPL.
No kernel 2.6.27 os firmwares foram movidos de dentro dos códigos do drivers para um novo diretório "firmware/". Por padrão, o firmware não será compilado dentro do kernel (built-in) ou nos módulos, mas serão instalados em /lib/firmware quando o usuário fizer o "make module_install". Os drivers foram modificados também para chamar a função request_firmware() e carregar o firmware que eles necessitarão.
Entretanto ainda há uma opção na configuração do kernel para que os firmwares sejam compilados dentro dos drivers.
Links relacionados:
LWN: Moving the firmware out (http://lwn.net/Articles/284932/)
WIKI: Firmware (http://en.wikipedia.org/wiki/Firmware)
- Improved video camera support with the gspca driver:
A inclusão do driver gspca no kernel 2.6.27 provê suporte a mais uma grande lista de câmeras de vídeo, que pode ser conferida aqui:
http://lwn.net/Articles/291036/
Agora, a maioria das câmeras de vídeo disponíveis no mercado são suportadas no Linux.
- Extended file descriptor system calls:
Quando o Unix foi criado, muitas das interfaces não previam funcionalidades que seriam necessárias no futuro, como por exemplo a criação de um descritor de arquivo que tivesse uma flag como parâmetro. Esta limitação tornava impossível a criação de descritores de arquivo com novas propriedades como "close-on-exec", "non-blocking" e "non-sequential". Tornar isso possível hoje é essencial, inclusive para efeitos de segurança.
O Linux 2.6.27 adicionou um novo set de interfaces e syscalls que serão usadas pela glibc.
Links relacionados:
LWN: Extending system calls (http://lwn.net/Articles/281965/)
WIKI: Descritor de arquivo (http://en.wikipedia.org/wiki/File_descriptor)
WIKI: Syscall (http://en.wikipedia.org/wiki/Syscall)
WIKI: Glibc (http://en.wikipedia.org/wiki/Glibc)
- Voltage and Current Regulator:
Este framework foi criado para implementar uma interface genérica com reguladores de voltagem e corrente. A intenção é permitir que os sistemas ajustem dinamicamente a saída do regulador com o objetivo de economizar bateria e gastar menos energia.
Outras novidades:
X86:
- Adicionado suporte ao AMD IOMMU (AMD I/O Virtualization Technology).
- Suporte a 4096 CPUs.
Xen:
- Permite que o Xen seja executado em 64-bits.
- O Xen agora permite que máquinas virtuais sejam salvas e restauradas.
PowerPC:
- Removida a arquitetura PPC (arch/ppc), agora a POWERPC (arch/powerpc) suporta as duas.
- Kdbg com suporte a PowerPC
Rede:
- Novos drivers ath9k que suportam os chipsets das famílias AR5008 e AR9001 da Atheros.
Segurança:
- O módulo de segurança "dummy" foi removido. Agora o padrão é o módulo "capabilities".
- Suporte aos seguintes algoritmos de hash: RIPEMD-128, RIPEMD-160, RIPEMD-256, RIPEMD-320.
Outros:
- Suporte ao Palm TX.
- Remoção da arquitetura v850.
E como sempre *muitos* novos drivers, aumentando ainda mais a gama de dispositivos suportados!
Fontes de informação/pesquisa:
http://lwn.net/Articles/289510/
http://lwn.net/Articles/290428/
http://lwn.net/Articles/291461/
http://kernelnewbies.org/Linux_2_6_27
Nenhum comentário:
Postar um comentário