Documentation/sched-arch.txt

   1         CPU Scheduler implementation hints for architecture specific code
   2
   3         Nick Piggin, 2005
   4
   5 Context switch
   6 ==============
   7 1. Runqueue locking
   8 By default, the switch_to arch function is called with the runqueue
   9 locked. This is usually not a problem unless switch_to may need to
  10 take the runqueue lock. This is usually due to a wake up operation in
  11 the context switch. See include/asm-ia64/system.h for an example.
  12
  13 To request the scheduler call switch_to with the runqueue unlocked,
  14 you must `#define __ARCH_WANT_UNLOCKED_CTXSW` in a header file
  15 (typically the one where switch_to is defined).
  16
  17 Unlocked context switches introduce only a very minor performance
  18 penalty to the core scheduler implementation in the CONFIG_SMP case.
  19
  20 2. Interrupt status
  21 By default, the switch_to arch function is called with interrupts
  22 disabled. Interrupts may be enabled over the call if it is likely to
  23 introduce a significant interrupt latency by adding the line
  24 `#define __ARCH_WANT_INTERRUPTS_ON_CTXSW` in the same place as for
  25 unlocked context switches. This define also implies
  26 `__ARCH_WANT_UNLOCKED_CTXSW`. See include/asm-arm/system.h for an
  27 example.
  28
  29
  30 CPU idle
  31 ========
  32 Your cpu_idle routines need to obey the following rules:
  33
  34 1. Preempt should now disabled over idle routines. Should only
  35    be enabled to call schedule() then disabled again.
  36
  37 2. need_resched/TIF_NEED_RESCHED is only ever set, and will never
  38    be cleared until the running task has called schedule(). Idle
  39    threads need only ever query need_resched, and may never set or
  40    clear it.
  41
  42 3. When cpu_idle finds (need_resched() == 'true'), it should call
  43    schedule(). It should not call schedule() otherwise.
  44
  45 4. The only time interrupts need to be disabled when checking
  46    need_resched is if we are about to sleep the processor until
  47    the next interrupt (this doesn't provide any protection of
  48    need_resched, it prevents losing an interrupt).
  49
  50         4a. Common problem with this type of sleep appears to be:
  51                 local_irq_disable();
  52                 if (!need_resched()) {
  53                         local_irq_enable();
  54                         *** resched interrupt arrives here ***
  55                         __asm__("sleep until next interrupt");
  56                 }
  57
  58 5. TIF_POLLING_NRFLAG can be set by idle routines that do not
  59    need an interrupt to wake them up when need_resched goes high.
  60    In other words, they must be periodically polling need_resched,
  61    although it may be reasonable to do some background work or enter
  62    a low CPU priority.
  63
  64         5a. If TIF_POLLING_NRFLAG is set, and we do decide to enter
  65             an interrupt sleep, it needs to be cleared then a memory
  66             barrier issued (followed by a test of need_resched with
  67             interrupts disabled, as explained in 3).
  68
  69 arch/i386/kernel/process.c has examples of both polling and
  70 sleeping idle functions.
  71
  72
  73 Possible arch/ problems
  74 =======================
  75
  76 Possible arch problems I found (and either tried to fix or didn't):
  77
  78 h8300 - Is such sleeping racy vs interrupts? (See #4a).
  79         The H8/300 manual I found indicates yes, however disabling IRQs
  80         over the sleep mean only NMIs can wake it up, so can't fix easily
  81         without doing spin waiting.
  82
  83 ia64 - is safe_halt call racy vs interrupts? (does it sleep?) (See #4a)
  84
  85 sh64 - Is sleeping racy vs interrupts? (See #4a)
  86
  87 sparc - IRQs on at this point(?), change local_irq_save to _disable.
  88       - TODO: needs secondary CPUs to disable preempt (See #1)
  89