| 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 arch/ia64/include/asm/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. |
| |
| 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/x86/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) |
| |