Ottawa Kernel Summit

A maior concentração de ~SKernel Hackers~T por metro quadrado em todo o mundo

Realizado nos dias 24 e 25 de Julho de 2002 na cidade de Ottawa, província de Ontário, Canadá, o Ottawa Kernel Summit reuniu desenvolvedores Linux de todo o mundo para discutir assuntos relacionados ao kernel do Linux, mais especificamente à série de desenvolvimento 2.5, que dará origem à próxima série estável do kernel, 2.6.

Representando o Brasil, estavam presentes Arnaldo Carvalho de Melo, conhecido como ACME e atual mantenedor da pilha IPX no kernel, e Marcelo Tossatti, mantenedor da série 2.4, ambos da Conectiva. Além dos tradicionais kernel hackers, representantes de grandes empresas, como AMD, IBM e HP, também estiveram presentes, mostrando mais de seus projetos com Linux ou ouvindo sugestões dos desenvolvedores. Acompanhe agora um resumo das principais palestras apresentadas durante os dois dias do evento:

Porte para a arquitetura AMD Hammer

Esta palestra foi como um ~Sstatus report~T do estado atual do porte do Linux para a Hammer, arquitetura de 64 Bits da AMD, que é uma extensão da arquitetura x86 de 32 Bits atual (ao contrário da arquitetura Itanium, da Intel, que ~Sreinventa a roda~T). Foram discutidos detalhes, como a implementação de certas chamadas de sistema (como a gettimeofday()) como ~Schamadas virtuais~T, que rodam no espaço do usuário, mas vivem numa região de memória separada, no final desse espaço, e o espaço de endereçamento virtual de 512 GB, para processos de 64 Bits (~Ssuficiente por enquanto~T, segundo um dos presentes), e 3.5 GB, para processos de 32 Bits

Parâmetros do Kernel

Parâmetros são apenas formas de controlar como o kernel opera. Podem ser especificados durante o boot, durante a carga de um módulo, durante a execução, através do /proc, ou de chamadas de sistema. Cada meio de receber parâmetros precisa de um pedaço diferente de código e, portanto nem todos os módulos implementam todas as formas acima citadas. Nesta apresentação, por Rusty Russell e Patrick Mochel, foram discutidos meios de unificar o manuseio de parâmetros do kernel.

Rusty Russell sugeriu a substituição da macro MODULE_PARAM por uma nova macro PARAM, que se encarregaria de receber parâmetros durante o boot, inserção do módulo e via /proc. O novo sistema é baseado num mecanismo de callback, que facilita para o módulo a definição de novos tipos de parâmetros, se necessário. Já Patrick Mochell apresentou driverfs, um sistema de arquivos virtual que facilita a visualização da estrutura de uma árvore de dispositivos. Contudo, o driverfs está atualmente limitado apenas a drivers de dispositivo, e discutiu-se se deveria ser ampliado para suportar parâmetros do kernel em geral.

~SVivendo com módulos~T

Em sua apresentação, Rusty Russel listou três tipos de problemas com módulos: de implementação, causados por interfaces pobres e subsistemas malfeitos; de inicialização, causados por módulos que simplesmente assumem que estão sendo executados durante o boot, possuem tratamento de erro inadequado ou não conseguem se recuperar de erros de inicialização; e de remoção.

Entre as soluções possíveis para os problemas de inicialização está a divisão de cada interface de registro no kernel em etapas de ~Sreserva~T e ~Suso~T: na primeira, o módulo alocaria os recursos necessários, expondo-os ao resto do sistema somente na etapa ~Suso~T, após toda a inicialização ter sido completada.

Quanto à remoção de módulos, por si só um problema, graças a vários motivos, entre os quais o fato de não haver como forçar a remoção de um módulo (e alguns módulos sequer são removíveis), várias alternativas foram apresentadas. A mais simples, e que agradou mais entre os presentes, foi a de simplesmente não remover os módulos. Afinal de contas, o preço de uma memória é baixo, módulos ocupam pouco espaço e sua remoção serve mais como ferramenta de debug, merecendo ser relegada à categoria de item opcional. Nenhuma decisão, porém, foi tomada.

Memória Virtual

Esta palestra, apresentada por Rik Van Riel e Andrea Arcangeli e moderada por Daniel Phillips, teve como seu primeiro tópico de discussão o patch de mapeamento reverso da memória virtual (reverse mapping VM patch), apresentado como um assunto polêmico, com Rik apontando suas vantagens, mas pronto para uma discussão sobre se, afinal de contas, os benefícios do mapeamento reverso justificam a ~Ssobrecarga~T imposta por ele. Linus disse que o patch deve entrar na série 2.5 em algum ponto, encerrando, de certo modo, o assunto.

Em seguida foram abordadas as questões de contabilização e gerenciamento de situações de falta de memória, tratadas pelo código atual da VM de Andrea Arcangeli. É interessante notar que é difícil para o kernel saber quando está sem memória e quantas páginas poderiam ser liberadas em um dado momento, através do término de processos em execução, caso necessário. Neste caso, usa-se a heurística para encontrar o ponto de equilíbrio do sistema. Se uma situação de falta de memória for declarada muito prematuramente, processos são mortos desnecessária e muito tardiamente e arrisca-se o travamento da máquina. O código atual de Andrea tende a matar processos em vez de arriscar travamentos. Entre outros temas abordados na palestra, estavam sistemas NUMA, tamanho das ~SSoft pages~T, páginas de memória muito grandes em sistemas que as suportem e clusterização de Swap, o armazenamento de blocos de memória em blocos contíguos do disco e melhor recuperação de estruturas de dados do sistema.

Bancos de Dados

Nesta apresentação, feita por Ken Rozendal, da IBM, foi discutida uma lista de recursos do Linux, necessários para melhor performance em grandes sistemas de bancos de dados. Muito do apresentado já é conhecido: I/O assíncrona, I/O direta, block I/O, páginas maiores, etc. Vários itens da lista já fazem parte da série 2.5, o que deve fazer o pessoal dos bancos de dados um pouco mais feliz. Resta esperar pela versão estável, a 2.6, para que estes recursos possam vir a ser usados em sistemas de produção.

Um ponto interessante levantado por Ken tem a ver com sistemas NUMA (Non Uniform Memory Access, Acesso Não Uniforme à Memória). Segundo ele, muitos sistemas com oito ou mais processadores são, internamente, NUMA, embora não sejam descritos como tal. Linus mencionou que mesmo sistemas desktop estão cada vez mais se parecendo com sistemas NUMA, como resultado do uso de processadores com hyperthreading. Portanto, técnicas para aumentar a performance em sistemas NUMA serão cada vez mais importantes no futuro.

Loadable Security Module

Chris Wright apresentou o Loadable Security Module (LSM), um patch que espalha 150 diferentes ~Sganchos~T pelo kernel, sendo que cada gancho se relaciona a um módulo de segurança com poder de veto sobre as ações de um determinado processo. A interface está estável há cerca de seis meses, e vários mecanismos de segurança já foram implementados sobre ela. O custo, em termos de performance, é pequeno, de zero a dois por cento, sem contar os custos adicionados por uma política de segurança específica. A grande exceção é a Gigabit Ethernet, que pode sofrer um impacto de cerca de vinte por cento na performance. Foi manifestado o interesse na possibilidade de desabilitar o LSM para operações de rede de baixo nível.

Embora não tenha dito que o patch está pronto para inclusão na série 2.5, Chris afirmou que ele necessita de mais exposição. Contudo, não houve grande feedback por parte da platéia, além da necessidade de uma olhada nos piores problemas de performance.

SCSI

Um dos passatempos preferidos dos desenvolvedores do Kernel é criticar o código responsável pelo suporte a sistemas SCSI. Esta palestra, apresentada por James Bottomley, foi iniciada com a pergunta: O código é realmente tão ruim assim? James afirma que o código está em melhor forma do que muitos pensam e que o que precisa ser realmente refeito são as rotinas de tratamento de erros. Claro que há código desnecessário, principalmente recursos que já foram úteis, mas que hoje são implementados no kernel. Conforme este vai maturando, o código genérico no kernel pode substituir funções realizadas na camada SCSI, que podem ser removidas.

O verdadeiro plano, contudo, é a remoção, na camada SCSI, de todo código entre o kernel e os drivers de alto nível (drivers de disco e fita, por exemplo) e a camada de baixo nível (que lida com o próprio adaptador SCSI ), já que boa parte deste código está migrando para outras partes do kernel, não sendo mais necessário. Muito trabalho vai ser necessário para que isso se realize, entretanto, e James Bottomley frisa que o suporte a SCSI tem que funcionar perfeitamente, já que é a chave do Linux para o mundo corporativo.

Kernel release management

A última palestra do segundo dia do Ottawa Kernel Summit, e a última do evento, foi sobre o gerenciamento do lançamento de novas versões do Kernel. Ted Ts'o abriu a seção afirmando que o esquema atual de freeze de uma versão não funciona adequadamente. Assim que um freeze é decretado, Linus acaba soterrado por uma imensa pilha de patches, aparentemente vindos do nada. Segundo Ted, seria melhor ter um conjunto bem definido de recursos que devem estar prontos na próxima versão e decretar, com antecedência, uma data para o freeze, quando novos recursos não podem mais ser adicionados ao kernel, sendo permitidas apenas correções de bugs.

Foi levantada a idéia de que uma nova série de desenvolvimento, a 2.7, deveria ser iniciada logo após o lançamento da versão 2.6, mas Linus teme que isso distraia muitos desenvolvedores, que deixariam de corrigir bugs na série estável. Também foi mencionada a idéia de se nomear um mantenedor para a próxima série estável durante o freeze. Este mantenedor trabalharia com Linus decidindo quais patches devem ir para a versão estável, assumindo, assim, a série 2.6 desde o começo. Isso levantou a questão: ~SQuem deverá ser o mantenedor da série 2.6?~T. Nesse momento, vários participantes foram vistos se escondendo atrás das mesas e poucos voluntários se apresentaram. Os nomes mais cotados foram os de Andrew Morton e Dave Jones, que não se comprometeram com a tarefa.

Embora uma lista dos recursos desejados na versão 2.6 não tenha sido definida, foi decidida a data para o freeze: 31 de Outubro de 2002, Halloween. Havia uma boa dose de otimismo durante a seção, com muitos esperando que as coisas saiam melhor desta vez do que na série 2.4, mas ainda há muito tempo até o freeze...

Para saber mais:

LWN: The Ottawa Kernel Summit - Day One lwn.net/Articles/3327/

LWN: The Ottawa Kernel Summit - Day Two lwn.net/Articles/3467/