Por qué deshabilitar las interrupciones deshabilita la preferencia del kernel y cómo el bloqueo de giro deshabilita la preferencia

No soy un gurú de los programadores, pero me gustaría explicar cómo lo veo. Aquí hay varias cosas.

1. preempt_disable() no deshabilita IRQ . Simplemente aumenta un thread_info->preempt_count variables.
2. Deshabilitar las interrupciones también deshabilita la preferencia porque el programador no funciona después de eso, pero solo en una máquina con una sola CPU. En el SMP no es suficiente porque cuando cierra las interrupciones en una CPU, la otra/otras todavía hacen/hacen algo de forma asíncrona.
3. El Big Lock (es decir, cerrar todas las interrupciones en todas las CPU) está ralentizando el sistema de forma espectacular, por lo que ya no está en uso. Esta es también la razón por la que preempt_disable() no cierra la IRQ.

Puedes ver qué es preempt_disable(). Prueba esto:1. Consiga un spinlock.2. Programación de llamadas()

En el dmesg, verá algo como "ERROR:programación mientras es atómico". Esto sucede cuando el programador detecta que su proceso está en un contexto atómico (no preventivo) pero se programa a sí mismo.

Buena suerte.

En un módulo de kernel de prueba que escribí para monitorear/perfilar una tarea, intenté deshabilitar las interrupciones por:

1 - Usando local_irq_save()

2 - Usando spin_lock_irqsave()

3 - Deshabilitar manualmente_irq() a todas las IRQ en /proc/interrupts

En los 3 casos, todavía podía usar el hrtimer para medir el tiempo aunque las IRQ estuvieran deshabilitadas (y una tarea que estaba monitoreando también se adelantó).

Encuentro esto muy extraño... Personalmente estaba anticipando lo que señaló Sebastian Mountaniol -> Sin interrupciones, sin reloj. Sin reloj, sin temporizadores...

Linux kernel 2.6.32 en un solo núcleo, una sola CPU... ¿Alguien puede tener una mejor explicación?