O novo escalonador do FreeBSD, disponível no RELENG_7, SCHED_ULE, é, de fato, um novo escalonador, tendo do SCHED_ULE antigo apenas o nome. Esse escalonador tem se mostrado não apenas muito bom, mas plagiando a consideração do Chris DiBona, gerente de projeto Open Source do Google, "SCHED_SMP is a masterpiece", algo como "SCHED_SMP é uma obra-de-arte", se referindo a quando SCHED_ULE era ainda chamado SCHED_SMP no FreeBSD 7.0-CURRENT.

Já divulgamos que os resultados de performance e resposta do FreeBSD com o novo escalonador comparado ao Linux, mesmo com seu novo escalonador - o CFS - ou Solaris, sejam em benchmarks práticos, com aplicações, como em testes de estresse sob grande load. Enfim, referências sobre o quão bom o escalonador se apresenta, ou como ele funciona, ou comparações dos modelos de decisão adotado neste ou em outros escalonadores podem ser observados em diversas referências (1 , 2, 3, 4 , 5 , 6, 7 , 8, 9 , 10 , 11 ...).

Mas o que interessa é, o FreeBSD adotará o SCHED_ULE em sua terceira encarnação, por padrão, a partir do RELENG_7? Sim, mas não a partir do FreeBSD 7.0-RELEASE. O escalonador em questão foi testado exaustivamente, e não apresenta problemas em nenhum ambiente, obtendo melhorias significativas em praticamente todo cenário. E então, porque não torna-lo padrão? Simples, o Projeto FreeBSD nunca foi conhecido por decisões arrojadas na condução de suas tecnologias. Mais que isso, sempre foi bastante conservador nessas decisões. O algorítimo de auto-tunning do maxusers é conservador. Um administrador FreeBSD mais bem preparado faz esse tuning sempre, de forma mais específica. O granularidade do sistema operacional há decadas justifica seu valor em 1000, e por anos, foi 100 (1000 se tornou padrão apenas recentemente), enquanto em arquiteturas 64bits pode ir facilmente para 2000 ou 3000. O que nunca é feito por padrão. Manter o SCHED_4BSD no kernel GENERIC no FreeBSD 7.0-RELEASE é só mais uma dessas decisões conservadores, que historicamente se tornou uma grande característica de condução do FreeBSD.

Isso demonstra a seriedade com que o Projeto aborda a adoção de tecnologia, e principalmente, o quanto requer que o usuário FreeBSD esteja ciente, com bastante antecipação, de modificações drásticas. O SCHED_ULE estará disponível no 7.0-RELEASE em sua melhor forma, mas não no GENERIC. Assim, todos poderemos ao longo do 7.0, trocar de escalonador, como um ítem adicional em nossa checklist.

Quando a árvore RELENG_7 estiver Open, em algum momento, durante o 7.0-STABLE, o SCHED_4BSD será substituído pelo ULE, e o planejamento é que no 7.1-RELEASE este já seja o escalonador no kernel GENERIC. Decisão apropriada, dada a importância de um RELEASE ponto-zero.

O hwpmc(4) existe no FreeBSD desde o início do ramo RELENG_6, e portanto está longe de ser uma novidade no sistema. Mas é pouco conhecido, e normalmente utilizado apenas por desenvolvedores ou administradores de sistema com conhecimento mais avançado, tal qual ktrace por exemplo. O que o hwpmc(4) faz é virtualizar os PMCs (Contadores de Medidas de Performance), recurso disponível praticamente em todos os processadores modernos, que mede informações de baixo nível em eventos de hardware como perda de cache de CPU, perda de TLB e antecipação errônea de ramificação de instruções.

Podendo virtualizar esses contadores, diversos processos podem, simultaneamente, utilizá-los, de forma concorrente. Com isso é possível obter modelos e profiling dessas informações, inclusive em operações em múltiplas CPU. Com isso pode-se rastrear todos os eventos de hardware que aconteçam, e comparar com os eventos que acontecem normalmente e poder identificar por exemplo, atividades incomuns.

Tudo bom, tudo muito bonito, mas qual a novidade? A divisão de código aberto do Google financiou o desenvolvimento de um novo recurso complementar no hwpmc(4) do FreeBSD, e a reimplementação parcial do recurso, que portanto, será no FreeBSD RELENG_7 diferente, internamente, do que temos até agora.

O novo, e a partir de agora principal recurso do hwpmc(4) é que o monitoramente das atividades não é mais passivo. Foi adicionado um recurso que permite a captura de chamadas realizadas pelas aplicações que disparam os eventos físicos na CPU, oferecendo mais informações e melhorando a percepção do comportamento do sistema. Resumidamente, agora é possível saber exatamente em que momento, no código da aplicação, os recursos de CPU são disparados, e fazer o profiling de que chamadas, em que laços do código ou sob que circunstâncias as atividades de CPU (notávelmente as incomuns) tornam-se mais ativas e presentes.

Esses "momentos" no código, são classificados de hot locations. Permitem aos desenvolvedores e administradores avançados de sistema identificar o motivo, com precisão, do consumo de recurso de CPU e principalmente comparar em tabelas de profiling as chamadas e trechos que, ao ser ativados, disparam a maior parte das instruções, oferecendo portanto estatística, complementarmente.

De acordo com Kris Kennaway, desenvolvedor FreeBSD, "hwpmc é uma das nossas ferramentas mais poderosas para medir e entender performance de CPU no FreeBSD. Suportar profiling de chamadas era um recurso importante que nãodispunhamos, e que agora simplifica a habilitado dos desenvolvedores em analizar gargalos de performance no kernel, em código de aplicações de nível de usário, e principalmente de entender seus motivos. Essas adições foram valiosas no ciclo de desenvolvimento do FreeBSD 7."

O desenvolvedor Kip Macy destaca que os novos recursos do hwpmc(4) foram de valor inestimável para o tuning do suporte FreeBSD a ambiente de 10Gbit/s - um dos projetos de destaque na lista da FreeBSD Foundation.

Você pode ler mais sobre as melhorias no hwpmc(4) no FreeBSD, nessa entrada do Google Code Blog, e também no breve relatório da Fundação FreeBSD , além do Wiki do Projeto.