FreeBSD/Linux Kernel Cross Reference
sys/Documentation/sched-arch.txt

             CPU Scheduler implementation hints for architecture specific code
     
             Nick Piggin, 2005
     
     Context switch
     ==============
     1. Runqueue locking
     By default, the switch_to arch function is called with the runqueue
     locked. This is usually not a problem unless switch_to may need to
    take the runqueue lock. This is usually due to a wake up operation in
    the context switch. See include/asm-ia64/system.h for an example.
    
    To request the scheduler call switch_to with the runqueue unlocked,
    you must `#define __ARCH_WANT_UNLOCKED_CTXSW` in a header file
    (typically the one where switch_to is defined).
    
    Unlocked context switches introduce only a very minor performance
    penalty to the core scheduler implementation in the CONFIG_SMP case.
    
    2. Interrupt status
    By default, the switch_to arch function is called with interrupts
    disabled. Interrupts may be enabled over the call if it is likely to
    introduce a significant interrupt latency by adding the line
    `#define __ARCH_WANT_INTERRUPTS_ON_CTXSW` in the same place as for
    unlocked context switches. This define also implies
    `__ARCH_WANT_UNLOCKED_CTXSW`. See include/asm-arm/system.h for an
    example.
    
    
    CPU idle
    ========
    Your cpu_idle routines need to obey the following rules:
    
    1. Preempt should now disabled over idle routines. Should only
       be enabled to call schedule() then disabled again.
    
    2. need_resched/TIF_NEED_RESCHED is only ever set, and will never
       be cleared until the running task has called schedule(). Idle
       threads need only ever query need_resched, and may never set or
       clear it.
    
    3. When cpu_idle finds (need_resched() == 'true'), it should call
       schedule(). It should not call schedule() otherwise.
    
    4. The only time interrupts need to be disabled when checking
       need_resched is if we are about to sleep the processor until
       the next interrupt (this doesn't provide any protection of
       need_resched, it prevents losing an interrupt).
    
            4a. Common problem with this type of sleep appears to be:
                    local_irq_disable();
                    if (!need_resched()) {
                            local_irq_enable();
                            *** resched interrupt arrives here ***
                            __asm__("sleep until next interrupt");
                    }
    
    5. TIF_POLLING_NRFLAG can be set by idle routines that do not
       need an interrupt to wake them up when need_resched goes high.
       In other words, they must be periodically polling need_resched,
       although it may be reasonable to do some background work or enter
       a low CPU priority.
    
            5a. If TIF_POLLING_NRFLAG is set, and we do decide to enter
                an interrupt sleep, it needs to be cleared then a memory
                barrier issued (followed by a test of need_resched with
                interrupts disabled, as explained in 3).
    
    arch/i386/kernel/process.c has examples of both polling and
    sleeping idle functions.
    
    
    Possible arch/ problems
    =======================
    
    Possible arch problems I found (and either tried to fix or didn't):
    
    h8300 - Is such sleeping racy vs interrupts? (See #4a).
            The H8/300 manual I found indicates yes, however disabling IRQs
            over the sleep mean only NMIs can wake it up, so can't fix easily
            without doing spin waiting.
    
    ia64 - is safe_halt call racy vs interrupts? (does it sleep?) (See #4a)
    
    sh64 - Is sleeping racy vs interrupts? (See #4a)
    
    sparc - IRQs on at this point(?), change local_irq_save to _disable.
          - TODO: needs secondary CPUs to disable preempt (See #1)
    

Cache object: 4d2477641ad31bb214d326a4010637fc