diff options
author | J. Bruce Fields <bfields@citi.umich.edu> | 2008-02-07 00:13:37 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2008-02-07 08:42:17 -0800 |
commit | 9b8eae7248dad42091204f83ed3448e661456af1 (patch) | |
tree | 1e300d41f8aaa9c258c179024ba63799a79f5a6f /Documentation/sched-arch.txt | |
parent | d3cf91d0e201962a6367191e5926f5b0920b0339 (diff) |
Documentation: create new scheduler/ subdirectory
The top-level Documentation/ directory is unmanageably large, so we
should take any obvious opportunities to move stuff into subdirectories.
These sched-*.txt files seem an obvious easy case.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Cc: Ingo Molnar <mingo@elte.hu>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation/sched-arch.txt')
-rw-r--r-- | Documentation/sched-arch.txt | 89 |
1 files changed, 0 insertions, 89 deletions
diff --git a/Documentation/sched-arch.txt b/Documentation/sched-arch.txt deleted file mode 100644 index 941615a9769b..000000000000 --- a/Documentation/sched-arch.txt +++ /dev/null @@ -1,89 +0,0 @@ - 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) - |