Documentation/scheduler/sched-arch

Chinese translated version of Documentation/00-INDEX

If you have any comment or update to the content, please contact the
original document maintainer directly.  However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help.  Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.

Chinese maintainer: LiuLu <[e-mail]>
---------------------------------------------------------------------
Documentation/00-INDEX 的中文翻译

如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。

中文版维护者： 刘璐  <[e-mail]>
中文版翻译者： 刘璐  <[e-mail]>
中文版校译者： 刘璐  <[e-mail]>

CPU Scheduler implementation hints for architecture specific code
        CPU 调度实现架构特定的代码


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.
默认情况下，switch_to函数被调用运行队列锁。这通常是没有问题的，除非，switch_to
可能需要采取的运行队列锁。这通常是由在上下文切换时胡一个唤醒操作的。见一个例子
arch/ia64/include/asm/system.h。


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).
要请求调度呼叫switch_to运行队列解锁，您必须在头文件添加
`＃define__ ARCH_WANT_UNLOCKED_CTXSW`
（通常由switch_to定义的一方）。


Unlocked context switches introduce only a very minor performance
penalty to the core scheduler implementation in the CONFIG_SMP case.
在CONFIG_SMP事件下，解锁上下文切换介绍的核心调度实施只是一个很小的性能损失。


CPU idle
CPU 闲置
========
Your cpu_idle routines need to obey the following rules:
你的CPU闲置例程必须遵循以下规则：


1. Preempt should now disabled over idle routines. Should only
   be enabled to call schedule() then disabled again.
1、抢占现在应该禁用胡闲置例程。先只启用schedule（），然后再禁用。


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.
2、只设置need_resched/ TIF_NEED_RESCHED的的，也永远不会被清零，
   直到正在运行的任务时间表（）。空闲线程只需要查询need_resched，
   并可能永远不会设置或清除它。


3. When cpu_idle finds (need_resched() == 'true'), it should call
   schedule(). It should not call schedule() otherwise.
3、当cpu_idle 发现 (need_resched() == 'true'）时，它自己就是schedule(). 
   不必再调用schedule()。


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).
4、 检查时，如果处理器是在睡眠状态，唯一一次中断就需要禁用need_resched，直到
    下一个中断（这不提供任何保护need_resched，它可以防止丢失中断）。




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.
   TIF_POLLING_NRFLAG由空闲的例程设置，当need_resched达到高峰时不需要
   中断唤醒他们。换句话说，他们必须定期轮询need_resched，做一些后台工
   作或优先进入低CPU也可能是合理的，
   


    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).
            如果设置了TIF_POLLING_NRFLAG，并且我们决定进入睡眠中断，
            它需要被清除，然后发出一个内存屏障（need_resched禁用中断
            测试，解释3）。


arch/x86/kernel/process.c has examples of both polling and
sleeping idle functions.
arch/x86/kernel/process.c 有所有轮换和睡眠待机功能的例子。


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.
        是这样睡眠活跃与中断？ （见＃4A）。
    我发现H8/300手册表示是肯定的，但是禁用的IRQ超过睡眠就只有NMI的可以
        唤醒它，所以没有做旋转等待是不能轻松地修复的。


ia64 - is safe_halt call racy vs interrupts? (does it sleep?) (See #4a)
       safe_halt 叫做活跃与中断？（是睡眠？）（见＃4A）


sh64 - Is sleeping racy vs interrupts? (See #4a)
       睡眠是活跃还是中断？（见＃4A）


sparc - IRQs on at this point(?), change local_irq_save to _disable.
      - TODO: needs secondary CPUs to disable preempt (See #1)
        IRQ在这一点上（？），改变local_irq_save to _disable。
        需要二次CPU的禁止抢占。（见 #1）