Se isso pareceu um pouco mais complicado, é porque ainda sim eu abstrai do texto as particularidades do hardware. Como vimos no último artigo, todo hardware tem uma datasheet, que é um documento técnico que descreve os circuitos internos, com informações de cada componente como tensão elétrica, indutância, capacitância, resistência elétrica etc. Além disso, a datasheet nos informa também quais os terminais do hardware recebem e enviam quais tipos de informação. E pensando em kernel e firmwares no geral, o mais importante, nos informa quais endereços de memória devem ser usados para cada ação. Não adianta a CPU pegar os dados da frase a ser imprimida na tela, jogar no barramento de dados e seguir a vida. Essa informação deve ser escrita para um endereço específico para que essa ação aconteça corretamente. E isso vale para qualquer hardware e qualquer ação, não só o nosso monitor hipotético. Um “simples” printf() parece bem mais complexo agora, certo?

Quando falamos que o kernel é o software que faz a ponte entre o hardware e o sistema operacional, muitas vezes a complexidade do que ele faz fica muito implícita, como o que podemos ver nesse exemplo que eu trouxe, e ainda sim nem mesmo arranhamos a superfície desse tópico, que seriam necessários alguns livros inteiros para abordá-lo com profundidade. De qualquer forma, fiz uma introdução bem longa sobre o que é um kernel, e já podemos agora discutir o tema principal, o Scheduler.

Como disse, o kernel é responsável pela comunicação entre hardware e SO, e uma das partes mais importantes dele (a mais importante na minha opinião, por motivos que ficarão evidentes ao longo desse artigo), é o scheduler. Mas bem, o que é o scheduler? Para responder essa pergunta vou ilustrar um problema, assim como fiz nos parágrafos anteriores. Como disse antes, toda vez que você executa um software no seu computador, o kernel atribui a este software um process ID (PID). Todos os softwares rodando no espaço de usuário, ou ring 3 (entrarei mais em detalhes sobre arquitetura de rings em artigos futuros), possuem seu próprio PID. Isso independe se estes softwares foram executados por você, automaticamente ao inicializar a máquina ou executados por um terceiro software. E isso é necessário por uma razão simples: uma CPU antigamente conseguia executar uma única instrução de cada vez, apenas uma por ciclo, e embora CPUs modernas possuam recursos Simultaneous Multi-Threading como o hyper Threading dos processadores Intel, um computador mesmo que em stand-by possui centenas de processos ativos. Quando pensamos nisso, é natural nos perguntarmos algo como: então como é possível ter, no meu computador, diversos softwares sendo executados ao mesmo tempo? É exatamente aqui que o scheduler entra: o scheduler é, em poucas palavras, o software responsável por administrar o uso de CPU por cada processo, gerenciando com latência de microsegundos o uso do tempo de CPU por centenas de processos simultaneamente, garantindo que todos os processos ativos consigam utilizar a CPU de acordo com a prioridade e minimizando o impacto da troca de contextos na performance. Conforme discutido por Arpaci-Dusseau & Arpaci-Dusseau¹ nos capítulos sobre escalonamento, o custo de um context switch envolve o salvamento e restauração do estado da CPU, incluindo registradores, program counter e TLB, podendo impactar significativamente a performance em sistemas com alta carga.

Ao compreendermos a função do scheduler conseguimos de imediato compreender como um computador consegue executar vários softwares “ao mesmo tempo”. A verdade é que ele está executando apenas um (ou alguns poucos, considerando tecnologias de SMT que citadas anteriormente), porém como o scheduler é capaz de alternar o uso de CPU entre milhares de processos em uma fração de segundos, temos a sensação de que são executados simultaneamente.

Agora que essa questão foi esclarecida, é natural que novas perguntas surjam. A mais importante é: mas como o scheduler organiza os processos e decide quem deve e quem não deve utilizar a CPU em um determinado momento?

Nota: As primeiras versões do kernel Linux e do Unix utilizavam algoritmos diferentes dos que são utilizados hoje. O scheduler do Kernel linux passou a utilizar o algoritmo conhecido como Completely Fair Scheduler em 2007, que embora tenha uma complexidade temporal de O(log n) de busca de processos na árvore red-black ele consegue dividir proporcionalmente o tempo de uso de CPU entre todos os processos, diferente do algoritmo anterior que, apesar de ser O(1) na busca de tarefas, utilizava uma janela de tempo baseada em prioridades, priorizando tarefas CPU-bound em detrimento das interativas, o que causava problemas de performance. Como o objetivo deste artigo não é discutir a história do scheduler e sim o que ele é e como funciona, focarei apenas no algoritmo utilizado nas versões modernas do kernel.²

Quando tomamos como exemplo o kernel Linux, o algoritmo utilizado atualmente pelo scheduler é conhecido como Completely Fair Scheduler (CFS). Esse algoritmo foca em distribuir o mais igualmente possível o tempo de uso de CPU entre todos os processos, e para isso ele organiza todos os processos em uma árvore Red-Black (Ou rubro negra, como a literatura brasileira prefere usar) baseando-se no Virtual Runtime (vruntime) de cada processo. O vruntime é, de forma simples, a quantidade de ciclos de CPU que um processo utilizou. Nesta árvore, os processos com menos vruntime são posicionados mais a esquerda, de maneira com que a árvore seja organizada com os processos que utilizaram menos vruntime para os que utilizaram mais, de maneira crescente, da esquerda para a direita. Quando o scheduler irá delegar o uso de CPU para um processo ele procura na árvore pelo processo com menos vruntime, ou seja, o mais a esquerda, e delega o uso de CPU para este processo. Na hora de trocar novamente de contexto ele interrompe este processo e salva seu estado, atualiza o vruntime e rebalanceia a árvore (como o vruntime deste processo agora é maior, ele será registrado na árvore mais a direita do que estava inicialmente) e então o processo é repetido. Um detalhe importante: o vruntime não é a medida de apenas uso de CPU, ele é uma medida ponderada que se baseia na prioridade dos processos. Em sistemas Unix e Unix-like (como o Linux) geralmente as prioridades (ou nice level) variam de -20 a 20, onde -20 é de prioridade crítica e 20 é o menos prioritário.

Figura 1: Representação de uma Red-Black tree com processos gerenciados pelo scheduler. Imagem retirada do portal da IBM. Fonte: https://developer.ibm.com/tutorials/l-completely-fair-scheduler/

Como uma cientista, o que mais me encanta na vida é que quando respondo uma pergunta, geralmente várias outras surgem. A primeira vez que estudei sobre o scheduler e entendi como ele gerenciava os processos, a primeira coisa que me veio a cabeça foi: mas como o algoritmo identifica o que está pronto para consumir CPU? Vamos tomar como exemplo um socket TCP. Imagina que você escreveu um programa que cria um socket TCP escutando na porta 3000, aguarda uma conexão e quando é realizada uma conexão ele escreve uma mensagem para o client, fecha o file descriptor da conexão e encerra a execução. Enquanto o seu software está aguardando uma conexão ele não está consumindo CPU. Na verdade ele não está fazendo nada, e delegar uso de CPU para ele nem mesmo faria sentido. Para lidar com estes casos, o scheduler possui uma tabela de status para os processos. Embora os nomes dos status sejam diferentes em cada kernel a funcionalidade é bem semelhante, então discutiremos aqui a lista de status do scheduler do kernel Linux:

Tabela 1: Status possíveis de um processo no scheduler.

Então no nosso exemplo do socket, enquanto o software estivesse aguardando uma conexão ele ficaria com o status TASK_INTERRUPTIBLE, e portanto fora da runqueue do scheduler. A parte mais interessante é que, enquanto na wait queue, este software não acumularia vruntime. Então ao receber uma conexão e voltar para TASK_RUNNING, como seu vruntime ficou congelado, ele estaria bem a esquerda na árvore, e portanto teria uma prioridade maior para uso de CPU.

Obrigada por lerem ate aqui! Neste artigo foi introduzido o CFS, mas ele é apenas uma das classes do scheduler, a SCHED_NORMAL. Existem outras classes como SCHED_FIFO e SCHED_IDLE, que serão abordadas em artigos futuros.

Bibliografia

Quem me acompanha já me viu falando sobre compiladores diversas vezes, um exemplo é neste post aqui em que faço algumas considerações sobre o compilador de C escrito em Rust da Anthropic criado puramente com agentes. Futuramente quero cobrir todas as etapas do processo de compilação aqui no blog, uma em cada post dedicado, mas hoje quero dedicar minha escrita ao Linker. Para relembrar, o processo de compilação de código em linguagem alto nível para linguagem de máquina contece em quatro etapas¹:

1. Preprocessamento: Aqui são removidos comentários, feitas substituições de strings etc
2. Tradução: O código fonte é convertido em instruções de CPU (Várias otimizações ocorrem aqui)
3. Assembly: Tradução das instruções de CPU para binário
4. Linker: Organização do executável final

Sim, eu sei que a etapa de Link é a última, mas quero começar o blog com ela por duas razões. A primeira é que, de todas elas, é a que menos falei até hoje, mesmo sendo a mais interessante de todas (pra mim!). A segunda é que, quando você lê que o linker organiza o binário, dá a entender que ele apenas troca coisas de lugar ou algo do tipo, sendo que o linker é, na verdade, o responsável por definir, por exemplo, o endereço de memória onde seu software será executado, os limites da stack etc¹.

Pois é, imagino que pra quem nunca tinha ouvido falar antes, agora deve ter uma noção melhor da importância do linker.

O linker é a etapa da compilação responsável por pegar todos os compilados intermediários (no caso de C os arquivos .o ou .a), e transformar em um único executável. Além disso ele também resolve toda a symbol table do seu software e as dependências. Se você tem declaradas as variáveis foo e bar, é ele quem decide o endereço final absoluto de memória onde essas variáveis ficarão localizadas. Se você importou bibliotecas externas, o linker é o responsável por alocar também a memória dos recursos utilizados por elas, endereço de memória das funções, tudo.

Normalmente, quando estamos escrevendo software que vai rodar em cima de um sistema operacional, é extremamente raro precisarmos escrever o script do linker, independente de estarmos trabalhando em C, Rust, Go etc. O compilador já faz esse trabalho por nós (e muito melhor do que uma pessoa conseguiria). Então, para este post aqui, resolvi ir um pouco abaixo do low-level tradicional que costumo postar e ir direto para o bare-metal. Escolhi um STM32, mais especificamente o STM32F103C8T6 também conhecido como blue-pill, pra criar esse exemplo. Escolhi ele porque é a placa que costumo utilizar nos meus projetos pessoais, e portanto a que tenho disponível aqui. Essa placa possui um processador ARM Cortex M3, e vai servir muito bem para mostrar como funciona o linker. Como estarei criando um driver simples do zero, utilizando apenas a datasheet da placa para mapear a memória na mão e manipular manualmente os registradores, o script do linker é bem mais curto e simples do que um script gerado por compilador, que está referenciando várias funções da stdlib, syscalls para o Kernel etc.

Não deixarei aqui neste post tudo que fiz para compilar a mão e gravar o código na memória Flash da placa, mas quem tiver interesse me sinalize que posso pensar em fazer um post dedicado a isso no futuro. Existem diversas IDEs que são super simples e prontas para programar essas placas, quase um plug-and-play, mas não é isso que vou fazer aqui. Pode não ser muito prático, mas criar seu próprio código manipulando o hardware, sem IDEs nem nada, utilizando apenas a datasheet fornecida pelo fabricante é uma das coisas mais recompensadoras na computação! Para quem tiver interesse, aqui está a datasheet desta placa específica, que utilizei para criar o código C e o script do Linker.

Retomando o tema do linker, imaginem o seguinte. Acabamos de colocar as mãos nessa plaquinha bonitinha e queremos testar. Qual a coisa mais simples que podemos fazer? Essa placa possui um LED embutido, que a datasheet nos informa ser o pino número 13. Podemos então, para fins de teste, tentar fazer este pino piscar.

Em tese é muito simples, mas como estamos fazendo tudo do zero, sem IDEs, libs externas nem nada, temos um problema. O STM32 não roda em um OS, então precisaremos criar uma Interrupt Vector Table (IVT) na mão. A IVT é uma tabela de ponteiros que mapeia sinais do hardware a funções de software. Um exemplo é quando você aperta Ctrl + C no seu terminal. Na IVT do seu Kernel está registrado que quando esse sinal do hardware for detectado, um determinado endereço de memória deve ser chamado. Nesse endereço está a função que interrompe a execução do seu programa.

Deixarei aqui um exemplo da IVT que codei para este nosso driver. Como não é o foco deste post não entrarei em detalhes, mas como disse antes, se for do interesse de vocês, posso fazer um post apenas sobre bare-metal no futuro:

int main();
void Reset_Handler(void);
void HardFault_Handler(void) __attribute__((weak));

__attribute__((section(".isr_vector")))
void (*const g_pfnVectors[])(void) = {
    (void (*)(void))0x20005000,
    Reset_Handler,
    HardFault_Handler,
};

void Reset_Handler(void) {
    extern unsigned int _sdata, _edata, _la_data;
    unsigned int *pSrc = &_la_data;
    unsigned int *pDest = &_sdata;
    while (pDest < &_edata) *pDest++ = *pSrc++;

    extern unsigned int _sbss, _ebss;
    pDest = &_sbss;
    while (pDest < &_ebss) *pDest++ = 0;

    main();
    while(1);
}

void HardFault_Handler(void) { while(1); }

E aqui deixarei o código para piscar o LED:

#define PERIPH_BASE     0x40000000
#define APB2PERIPH_BASE (PERIPH_BASE + 0x10000)
#define AHBPERIPH_BASE  (PERIPH_BASE + 0x20000)

#define RCC_BASE        (AHBPERIPH_BASE + 0x1000)
#define GPIOC_BASE      (APB2PERIPH_BASE + 0x1000)

#define RCC_APB2ENR     (*((volatile unsigned int*)(RCC_BASE + 0x18)))
#define GPIOC_CRH       (*((volatile unsigned int*)(GPIOC_BASE + 0x04)))
#define GPIOC_ODR       (*((volatile unsigned int*)(GPIOC_BASE + 0x0C)))

void delay(volatile unsigned int count) {
    while(count--);
}

int main(void) {
    RCC_APB2ENR |= (1 << 4);

    GPIOC_CRH &= ~(0xF << 20);
    GPIOC_CRH |= (0x3 << 20);

    while(1) {
        GPIOC_ODR &= ~(1 << 13);
        delay(500000);
        GPIOC_ODR |= (1 << 13);
        delay(500000);
    }
}

void SystemInit(void) {  }

Para não deixar tudo sem explicação: Como informado na documetação da placa, a memória RAM começa a partir do endereço 0x20000000, e por isso declarei o início da Stack bem próximo. A datasheet também nos informa que a IVT deve ficar no endereço de memória 0x08000000, que também é o início da memória flash, e temos também as informações dos pinos e registradores, que utilizei para escrever os endereços de memória corretos.

Ok, temos nosso código, hora de escrever nosso linker!

MEMORY {
    FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 64K
    RAM (rwx)   : ORIGIN = 0x20000000, LENGTH = 20K
}
ENTRY(Reset_Handler)

SECTIONS {
    .isr_vector : { KEEP(*(.isr_vector)) } > FLASH
    .text : { *(.text) *(.text*) } > FLASH
    .rodata : { *(.rodata) *(.rodata*) } > FLASH
    _la_data = LOADADDR(.data);
    .data : {
        _sdata = .;
        *(.data) *(.data*);
        _edata = .;
    } > RAM AT> FLASH
    .bss : {
        _sbss = .;
        *(.bss) *(.bss*) *(COMMON);
        _ebss = .;
    } > RAM
}

Essa aqui é, na minha opinião, a parte mais linda da etapa de compilação. Vamos ver o que está acontecendo:

• Campo MEMORY
  • Alí definimos duas variáveis: FLASH e RAM. Memória flash é aquela usada como “disco”, é onde ficará registrado o binário compilado do nosso software. Dizemos no linker que essa memória iniciará no endereço 0x08000000, e que ela tem tamanho de 64Kb. Ambas as informações nos foram fornecidas pela datasheet. Reparem que alí definimos a Flash como read only e a RAM como read and write.
  • Na variável RAM seguimos o mesmo padrão, utilizamos as informações da datasheet para mapear seu tamanho e onde começa.
• Campo ENTRY
  • Aqui estamo dizendo para o linker o seguinte: Assim que o hardware bootar, o primeiro código executado é essa função. O hardware do Cortex-M3 automaticamente procura pelo endereço do Reset_Handler dentro da nossa IVT (lembra dela?) para saber por onde começar a rodar nosso programa.
• Campo SECTIONS
  • É exatamente aqui que mapeamos onde tudo vai ficar. Deixamos claro no linker, assim como manda a datasheet, que a IVT ficará no primeiro endereço da memória Flash
  • Depois vem a sessão .text. Na linguagem do linker, .text é a sessão onde fica todo o código compilado do nosso software, também armazenado na memória Flash.
  • .rodata é uma abreviação de Read Only data. Todas as constantes do nosso software ficarão armazenadas neste segmento de memória.
  • .data aqui já é a nossa primeira sessão de memória alocada na RAM. Todas as variáveis inicializadas vivem nesta sessão. Mas detalhe: essas variáveis começam a vida gravadas na Flash (para não serem perdidas quando a placa desligar). É o nosso Reset_Handler que as copia para a RAM (usando os símbolos _sdata e _edata criados aqui no linker) logo antes do main() rodar.
  • .bss esse bloco é bem interessante. Aqui ficam todas as variáveis globais e variáveis estáticas não inicializadas. Elas são armazenadas em um único bloco contínuo de RAM

Nesse script, estamos basicamente dizendo ao compilador onde tudo deve ser posicionado, para que o software consiga se comunicar perfeitamente com o hardware. O linker é quem faz o software entender o hardware.

Deixei aqui uma foto da placa funcionando. A placa preta é um conversor de USB para UART, que precisei utilizar para escrever direto da porta USB do meu Mac para a STM. Espero que tenham gostado, e que tenha sido possível aprender um pouco mais sobre como os softwares são compilados!

Bibliografia