O diferencial do BeOS / Haiku

O ponto central é simples: escalonar no nível da thread, com threads muito leves e políticas que favorecem responsividade em vez de throughput máximo. Isso reduz a sobrecarga de contexto ao trocar entre threads da mesma aplicação e permite uma taxa alta de comutação sem penalizar a interatividade.

Essa ênfase na responsividade ajuda a explicar decisões de projeto aparentemente simples — por exemplo, por que tratar a unidade de escalonamento como a thread em vez do processo — e prepara o terreno para entendermos o conceito que vem a seguir.

O que é Pervasive Multithread

Pervasive Multithread é um modelo composto — kernel e runtime cooperam — em que o sistema trata a concorrência como algo onipresente: o scheduler opera por thread, há prioridades finas (tipicamente 0–120) e políticas que privilegiam latência e previsibilidade sobre o rendimento bruto.

O resultado prático é que a aplicação vê threads leves com prioridades ajustáveis, e o kernel faz o mínimo necessário ao salvar/restaurar contexto, mantendo a máquina responsiva para cargas interativas.

Com essa definição em mente, vale contrastar como o hardware moderno tenta aumentar paralelismo com técnicas como SMT — e por que essa camada física pode confundir as decisões de escalonamento quando não é considerada explicitamente.

Por que SMT não é um “CPU” — explicação técnica

Simultaneous multithreading (SMT) cria múltiplas hardware threads dentro do mesmo núcleo físico. Essas hardware threads compartilham pipelines, unidades funcionais, níveis de cache e o mesmo domínio energético. Em particular:

• Compartilhamento de execution units: duas hardware threads podem disputar as mesmas ALUs, FPU e portas de memória.
• Contenção em caches: L1 e, em muitos designs, partes do L2/L3 são compartilhadas ou têm efeitos de conflito entre threads.
• Dependência de largura de banda e buffers internos: estruturas como reorder buffers e filas de load/store são limitadas por núcleo.

Esses recursos compartilhados significam que duas hardware threads no mesmo núcleo não oferecem isolamento equivalente ao de dois núcleos físicos. Tratar cada hardware thread como uma CPU independente ignora dependências microarquiteturais e pode degradar throughput e previsibilidade ao induzir contenção e conflitos que o sistema não prevê.

Em outras palavras: o escalonador que vê apenas “CPUs lógicas” perde contexto sobre contendas internas do núcleo — um fator crítico quando buscamos baixa latência e previsibilidade.

Onde os schedulers modernos erram

Muitos escalonadores expõem cada hardware thread lógico como uma CPU separada (p. ex. quando htop mostra “cores lógicos”). Essa abstração facilita balanceamento de carga, mas apaga a topologia real: quando cargas pesadas são espalhadas por hardware threads de um mesmo núcleo, surgem colisões internas que reduzem performance por watt e aumentam a variabilidade de latência.

O problema não é apenas teórico: medições podem mostrar degradação de throughput e latência em cenários que misturam cargas intensivas de CPU e sensíveis à latência, especialmente quando o escalonador não considera a afinidade por núcleo físico e a partição de recursos.

Por isso é importante que camadas de software acima do escalonador compreendam a topologia do processador ou que o próprio escalonador exponha políticas que evitem colocar cargas conflitantes em hardware threads do mesmo núcleo.

A proposta do FKernel: consciência de topologia

No FKernel, a responsabilidade de lidar com essa complexidade é deslocada para camadas que entendem o perfil da carga. A ideia central é uma pipeline decidida antes do despacho para hardware threads:

Green Threads → Multilevel Feedback Queue (MLFQ) → Pervasive Layer → Hardware Threads (SMT)

Detalhes práticos:

• O MLFQ organiza e amostra comportamento das green threads para estimar sua sensibilidade à latência e ao throughput.
• A Pervasive Layer usa esse perfil para decidir mapeamentos: algumas execuções ocupam uma hardware thread sozinho (para evitar contenda), outras são pareadas com cargas complementares para aproveitar vazios da unidade funcional.

Isso torna o SMT um recurso gerenciado — um “acelerador” que é usado conscientemente e não um substituto direto de um núcleo físico.

Na prática, isso permite duas estratégias opostas: isolar workloads sensíveis à latência em hardware threads próprias, ou cooperar uma workload de alta utilização com outra complementar para maximizar uso de unidades funcionais sem bloquear latência crítica.

Flag O_HPC — atalho para throughput

Para workloads puramente orientados a throughput, o desenvolvedor pode usar a flag O_HPC. Nesse modo, o caminho é encurtado: a aplicação solicita pinagem e afinidade mais agressivas (possivelmente com garantia de partição de cache L2/L3), sacrificando previsibilidade para ganhar rendimento bruto.

Em resumo, O_HPC é uma exceção explícita ao modelo orientado a latência — uma forma de o desenvolvedor indicar que prefere rendimento bruto em vez de previsibilidade quando as medições justificam essa escolha.

Conclusão

Tratar hardware threads SMT como CPUs independentes é uma simplificação que não reflete a microarquitetura moderna: ela produz contenção interna, variabilidade de latência e desperdício de recursos. O FKernel propõe empurrar a complexidade para camadas que conhecem o perfil das cargas — MLFQ e Pervasive Layer — para mapear threads de forma consciente sobre a topologia real do processador.

O ganho esperado é simples e direto: menor latência, interatividade consistente e uso mais eficiente de caches e unidades funcionais. Para cargas de throughput extremo, a flag O_HPC permite abrir mão dessa previsibilidade de propósito.

Se você curte esse tipo de discussão ou quer acompanhar o desenvolvimento do FKernel, deixe um comentário, compartilhe como seu sistema lida com SMT ou sugira cargas de trabalho para testarmos. Medições práticas mostrarão o impacto real, e pretendo publicar os resultados em posts futuros.

Para uso desktop em código x86_64.

E lendo sobre algumas linguagens como Rust, C, C++, Zig …

Decidi fazer uma combinação de:

• Linguagens de Programação:
  • C
  • C++
• Linguagem de montagem:
  • Nasm

Obviamente alguns podem estranhar já que eu propositalmente ignorei Rust, e aquelas que são considerados “memory-safe”.

Por que não usar linguagens memory-safe?

Pro Tip: Não existe linguagem memory-safe em baixo nível. Para programar um kernel ou similar, você vai depender do unsafe então nem tenta.

Se for para ter que lidar com sintaxes estranhas para programar um kernel, eu prefiro seguir no bom e velho C/C++.

Também não quero fazer um overflow de logs de um compilador super-nanny para chegar a um subset daquilo que eu queria no meu código.

E por que C++?

Muito tempo atrás Linus Torvalds havia tentado escrever um kernel com a versão de sua época.

C++ leads to really, really bad design choices. You invariably start using the STL, boost, and other total and utter crap…

Ok, podemos concordar em algumas partes mas, isso não seria inevitavelmente ruim.

Sim, C++ tem um monte de coisa, mas fugiria do ponto principal que é C++ dá contratos que structs sozinhas dificilmente conseguem.

Pegue um exemplo do SerenityOS

static ErrorOr<NonnullOwnPtr<KBuffer>> try_create_with_size(StringView name,
size_t size,
Memory::Region::Access access = Memory::Region::Access::ReadWrite,
AllocationStrategy strategy = AllocationStrategy::Reserve){
  auto rounded_size = TRY(Memory::page_round_up(size));
  auto region = TRY(MM.allocate_kernel_region(rounded_size, name, access, strategy));
  return TRY(adopt_nonnull_own_or_enomem(new (nothrow) KBuffer { size, move(region) }));
}

Consegue entender o que esse código faz? Todo esse contrato engloba em poucas linhas

Essa função try_create_with_size serve para criar um buffer de memória no kernel de um tamanho específico e lidar com possíveis erros de forma segura.

Para termos o equivalente exato em C garantindo a mesma segurança seria necessária escrever dessa forma.

int try_create_with_size(const char* name,
                         size_t size,
                         MemoryAccess access,
                         AllocationStrategy strategy,
                         KBuffer** out_buffer) {
    if (!out_buffer) return -1;

    size_t rounded_size;
    int rc = page_round_up(size, &rounded_size);
    if (rc != 0) return rc;

    MemoryRegion* region;
    rc = allocate_kernel_region(rounded_size, name, access, strategy, &region);
    if (rc != 0) return rc;

    KBuffer* buffer = malloc(sizeof(KBuffer));
    if (!buffer) {
        free(region->addr);
        free(region);
        return -ENOMEM;
    }

    buffer->size = size;
    buffer->region = region;
    *out_buffer = buffer;

    return 0; // sucesso
}

Ok, tivemos uma disparidade no tamanho, mas isso não significa nada no geral.

Meu ponto defendido é que precisamos fazer muito mais código, que vai ser muito mais performático mas que vai resultar em um resultado muito menos seguro, e muito menos reusável no geral.

Não ironicamente, muitos empresas incluindo a própria Apple usam o C++ em seus kernels.

Mas não precisa ser o c++ inteiro e sim um subset chamado embedded c++.

Implementação do IOKit

/*
 * Copyright (c) 1998-2000 Apple Computer, Inc. All rights reserved.
 *
 * @APPLE_OSREFERENCE_LICENSE_HEADER_START@
 *
 * This file contains Original Code and/or Modifications of Original Code
 * as defined in and that are subject to the Apple Public Source License
 * Version 2.0 (the 'License'). You may not use this file except in
 * compliance with the License. The rights granted to you under the License
 * may not be used to create, or enable the creation or redistribution of,
 * unlawful or unlicensed copies of an Apple operating system, or to
 * circumvent, violate, or enable the circumvention or violation of, any
 * terms of an Apple operating system software license agreement.
 *
 * Please obtain a copy of the License at
 * http://www.opensource.apple.com/apsl/ and read it before using this file.
 *
 * The Original Code and all software distributed under the License are
 * distributed on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
 * EXPRESS OR IMPLIED, AND APPLE HEREBY DISCLAIMS ALL SUCH WARRANTIES,
 * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
 * Please see the License for the specific language governing rights and
 * limitations under the License.
 *
 * @APPLE_OSREFERENCE_LICENSE_HEADER_END@
 */

#ifndef _IOKIT_IONVRAMCONTROLLER_H
#define _IOKIT_IONVRAMCONTROLLER_H

#include <IOKit/IOService.h>

class IONVRAMController : public IOService
{
	OSDeclareAbstractStructors(IONVRAMController);

public:
	virtual void registerService(IOOptionBits options = 0) APPLE_KEXT_OVERRIDE;

	virtual void sync(void);
	virtual IOReturn select(uint32_t bank);
	virtual IOReturn eraseBank(void);

	virtual IOReturn read(IOByteCount offset, UInt8 *buffer,
	    IOByteCount length) = 0;
	virtual IOReturn write(IOByteCount offset, UInt8 *buffer,
	    IOByteCount length) = 0;
};

#endif /* !_IOKIT_IONVRAMCONTROLLER_H */

Quem diria.

Se fossemos falar do C++ antes da versão 17, eu até concordaria mas após a versão 17 muita coisa mudou.

E veja que o IOKit é implementado na forma Embedded C++.

Mas, e como em tudo há um mas, há em real,o ponto da STL que invariavelmente você vai acabar usando ou não.

Realmente preciso do STL?

No fringir dos ovos há um outro superset de C++ chamado c++ ortodoxo jamais o use, sério.

Uma das soluções que o FKernel e o SerenityOS fazem é criar sua própria STL.

O SerenityOS com sua Abstraction Kit. E o FKernel com seu LibFK.

Usar uma STL não é de todo mal, há diversos efeitos, como otimização em cascata.

Genericos e todo resto.

E no fim?

No fim, depende de você.

Se você está desenvolvendo um app para desktop.

Eu sugeriria:

• D
• Go
• Zig
• Rust

Para baixo nível certamente eu sugeriria:

• B
• C,
• C++
• D
• Rust
• Zig

Mas em kernel estou muito mais satisfeito com minha escolha do que usar C puro.

Não que eu não use C obviamente, por baixo dos panos da LibFK eu implementei uma LibC bem simples com funções que eu teria que usar dentro do FKernel para algumas funções da LibFK.

Mas enfim, se uma linguagem que você prefere usar por algum motivo de design ou simplesmente por ser a que você sabe, simplesmente use.

Desde que não seja usar algo interpretado para fazer baixo nível, tá valendo tudo.