Documentation/translations/zh_CN/scheduler/sched-arch.rst

   1 .. include:: ../disclaimer-zh_CN.rst
   2
   3 :Original: Documentation/scheduler/sched-arch.rst
   4
   5 :翻译:
   6
   7  司延腾 Yanteng Si <siyanteng@loongson.cn>
   8
   9 :校译:
  10
  11
  12
  13 ===============================
  14 架构特定代码的CPU调度器实现提示
  15 ===============================
  16
  17         Nick Piggin, 2005
  18
  19 上下文切换
  20 ==========
  21 1. 运行队列锁
  22 默认情况下，switch_to arch函数在调用时锁定了运行队列。这通常不是一个问题，除非
  23 switch_to可能需要获取运行队列锁。这通常是由于上下文切换中的唤醒操作造成的。
  24
  25 为了要求调度器在运行队列解锁的情况下调用switch_to，你必须在头文件
  26 中`#define __ARCH_WANT_UNLOCKED_CTXSW`(通常是定义switch_to的那个文件）。
  27
  28 在CONFIG_SMP的情况下，解锁的上下文切换对核心调度器的实现只带来了非常小的性能损
  29 失。
  30
  31 CPU空转
  32 =======
  33 你的cpu_idle程序需要遵守以下规则：
  34
  35 1. 现在抢占应该在空闲的例程上禁用。应该只在调用schedule()时启用，然后再禁用。
  36
  37 2. need_resched/TIF_NEED_RESCHED 只会被设置，并且在运行任务调用 schedule()
  38    之前永远不会被清除。空闲线程只需要查询need_resched，并且永远不会设置或清除它。
  39
  40 3. 当cpu_idle发现（need_resched() == 'true'），它应该调用schedule()。否则
  41    它不应该调用schedule()。
  42
  43 4. 在检查need_resched时，唯一需要禁用中断的情况是，我们要让处理器休眠到下一个中
  44    断（这并不对need_resched提供任何保护，它可以防止丢失一个中断）:
  45
  46         4a. 这种睡眠类型的常见问题似乎是::
  47
  48                 local_irq_disable();
  49                 if (!need_resched()) {
  50                         local_irq_enable();
  51                         *** resched interrupt arrives here ***
  52                         __asm__("sleep until next interrupt");
  53                 }
  54
  55 5. 当need_resched变为高电平时，TIF_POLLING_NRFLAG可以由不需要中断来唤醒它们
  56    的空闲程序设置。换句话说，它们必须定期轮询need_resched，尽管做一些后台工作或
  57    进入低CPU优先级可能是合理的。
  58
  59       - 5a. 如果TIF_POLLING_NRFLAG被设置，而我们确实决定进入一个中断睡眠，那
  60             么需要清除它，然后发出一个内存屏障（接着测试need_resched，禁用中断，如3中解释）。
  61
  62 arch/x86/kernel/process.c有轮询和睡眠空闲函数的例子。
  63
  64
  65 可能出现的arch/问题
  66 ===================
  67
  68 我发现的可能的arch问题（并试图解决或没有解决）。:
  69
  70 sparc - 在这一点上，IRQ是开着的（？），把local_irq_save改为_disable。
  71       - 待办事项: 需要第二个CPU来禁用抢占 (参考 #1)