Por que o spin bloqueia as boas escolhas no Linux Kernel Design em vez de algo mais comum no código da terra do usuário, como semáforo ou mutex?

Question

Eu entendo que os Spinlocks são um desperdício real no Design de Kernel do Linux.

Eu gostaria de saber porque é que os bloqueios de spin são boas escolhas no Linux Kernel Design em vez de algo mais comum em código de usuário, como semáforo ou mutex?

    

Answer 1

A escolha entre um spinlock e outra construção que faz com que o chamador bloqueie e abandone o controle de uma cpu é em grande parte controlada pelo tempo que leva para executar uma alternância de contexto (salvar registradores / estado no encadeamento de bloqueio e restaurar registra / estado em outro segmento). O tempo gasto e também o custo do cache para fazer isso pode ser significativo.

Se um spinlock estiver sendo usado para proteger o acesso a registradores de hardware ou similares, onde qualquer outro thread que estiver acessando só levará uma questão de milissegundos ou menos antes de liberar o bloqueio, então é um uso muito melhor do tempo da CPU para girar a espera, em vez de mudar de contexto e continuar.

    

Answer 2

Como a questão implica em dizer que os spinlocks são um "desperdício", os spinlocks devem ser mantidos apenas brevemente.

Spinlocks não são a única maneira de sincronizar vários segmentos. Mutexes / semáforos também são usados no kernel do Linux, assim como outras primitivas de sincronização (por exemplo, waitqueues, events).

No entanto, o kernel tem que lidar com casos que o userspace nunca vê, um comum sendo manipuladores de interrupção. Os manipuladores de interrupção não podem ser reprogramados no Linux, mas geralmente precisam usar alguma primitiva de sincronização (por exemplo, para adicionar um item de trabalho a uma lista vinculada que algum outro segmento processará posteriormente). Como os handlers de interrupção não conseguem dormir, eles não podem usar mutexes, waitqueues, etc. Isso praticamente deixa spinlocks. Se um encadeamento precisar sincronizar o acesso com um manipulador de interrupções, ele também deverá usar o mesmo spinlock.

Os Spinlocks não são necessariamente um desperdício. Eles são otimizados para o caso de não-contenção / não-espera e podem ser tomados e liberados muito rapidamente. Nesse caso, eles são mais rápidos e envolvem menos sobrecarga do que outras primitivas de sincronização.

    

Answer 3

Outras pessoas responderam. Vou resumir os casos em que você usaria spinlock e regras para usar o spinlock.

1. Quando o spinlock é usado?

Resp: Nas seguintes situações.

1. O encadeamento que contém o bloqueio não tem permissão para dormir.
2. O encadeamento que está aguardando um bloqueio não dorme, mas gira em um loop apertado.

Quando usado corretamente, o spinlock pode oferecer um desempenho maior que o semáforo. Ex: Manipulador de intromissão.

2. Quais são as regras para usar spinlocks?

Resposta:

Regra - 1: Qualquer código que contenha o spinlock, não pode abandonar o processador por qualquer motivo, exceto para interromper o serviço (às vezes nem assim). Então, o código segurando spinlock não pode dormir.

Razão: suponha que o seu motorista segurando o spinlock entra no modo de suspensão. Ex: chama a função copy_from_user() ou copy_to_user() , ou a preempção do kernel entra em ação, então o processo de prioridade mais alta empurrou seu código para o lado. Efetivamente, o processo abandona a CPU que contém o spinlock.

Agora não sabemos quando o código liberará o bloqueio. Se algum outro thread tentar obter o mesmo bloqueio, ele girará por muito tempo. No pior dos casos, isso resultaria em deedlock.

O caso de preempção do kernel é tratado pelo próprio código de spinlock. Sempre que o código do kernel contém um spinlock, a preempção é desativada no processador relevante. Mesmo o sistema de uniprocessador deve desativar a preempção dessa maneira.

Regra - 2: Desativa as interrupções na CPU local, enquanto o spinlock é mantido.

Razão: Apoiar seu motorista a fazer um spinlock que controle o acesso ao dispositivo e, em seguida, emita uma interrupção. Isso faz com que o manipulador de interrupção seja executado. Agora o manipulador de interrupção também precisa do bloqueio para acessar o dispositivo. Se o manipulador de interrupções for executado no mesmo processador, ele começará a girar. O código do driver também não pode ser executado para liberar o bloqueio. SO o processador girará para sempre.

Regra - 3: Os Spinlocks devem ser mantidos pelo menor tempo possível.

Razão: Longo tempo de bloqueio também mantém o processador atual de agendamento, o que significa que um processo de maior prioridade pode ter que esperar para obter a CPU.

Por isso, afeta a latência do kernel (tempo que um processo pode ter que esperar para ser agendado). Normalmente, os spinlocks devem ser mantidos pela duração do tempo, menos do que a CPU leva para fazer uma alternância de contexto entre os threads.

Regra -4: se você tiver semáforos e spinlocks a serem pegos. Então, pegue o semáforo primeiro e depois o spinlock.

    

Answer 4

Spinlocks e amp; mutexes são usados devido à falta de recursos na CPU. Eles estão se tornando um legado redundante de design de Von Neumann baseado no registrador de 8 bits, que é a pior arquitetura, totalmente ilógica para aderir neste dia & idade.

Os recursos de compilador Unfort, C / C ++ se tornaram desproporcionais ao hardware em recursos que simplesmente não podem ficar presos em hardware com os recursos arcaicos no chip ainda existentes até hoje. Os caches simplesmente não são reentrantes além do segundo nível em um Uniprocessador, assim o tempo consome economia e cargas de SMP re-entrantes continuam .. O futuro está em dispositivos FPGA, tendo ferramentas de construção otimizadas .. A Xilinix tem um novo processo de 14nm com 3000 interconexões entre os núcleos A9 e os arranjos de portas programáveis , que suporta até centenas de mega bits de SRAM em tabelas para aproveitar o avançado projeto de máquina de estado, capaz de reduzir aritmética / vetor multi-dimensional / redução de tabela própria .. muito mais do que o seu antigo compilador de cadeira de rodas com fio.

Meu design de hardware há 25 anos incorporou hardware aumentado em uma interface DSP AD 21020 / CPU i960 ... ficou claro que o design aumentado resolveu muitas dores de cabeça de software nessa impressora de bico de 160 metros de largura e intensidade intensiva.

Pessoas capacitadas no desenvolvimento do Kernel, convidadas a formar uma pequena equipe para avaliar / modificar uma nova arquitetura que tenha potencial para substituir condições de SMP de spinlocks / cache / re-entrantes.