CPU架构的几个问题

Perlvim

关于CPU架构的几个问题。

关于硬件栈的问题，是不是过程的定义模式，已经成为硬件架构的一部分？

关于一级，二级，甚至三级缓存的数据空间，是不是不能进行地址映射，通过代码透明的进行管理？

上下文切换的所有暂存信息，是保存在哪里？

wait_rabbit

不明白“过程的定义模式”是什么意思。

映射缓存？映射到哪儿去？能解释一下吗，没看懂。对cache的管理是硬件实现的，软件工程师没办法直接控制。顶多也就是写程序的时候，注意利用cache的替换算法，提高代码效率。

上下文保存在当前的内核栈上。

Perlvim

过程的定义模式是指利用栈顶保存入口地址和传入的参数，栈底返回的参数，和返回地址的过程定义模式。

当前的内核栈保存的数据实际上保存在缓存中还是保存在内存中。每次上下文切换需要大概多少个时钟的延时？

灌水菜鸟

回复 3# Perlvim


上下文切换的时间。Function trace 有可能对你的需求有帮助。如果确实关注最底层的操作，可以直接分析context_switch和相关的二进制汇编。

wait_rabbit

http://www.ibm.com/developerwork ... rt/part9/index.html

文章是02年的了，数据可以参考一下。都是微妙级的。

"在 UNIX 中有一种众所周知的简单测试，那就是创建两个进程并在它们之间传送一个令牌，如此往返传送一定的次数。其中一个进程在读取令牌时就会引起阻塞。另一个进程发送令牌后等待其返回时也处于阻塞状态。发送令牌带来的开销与上下文切换带来的开销相比，可以忽略不计。这样，您就可以测算出每秒钟进行的上下文切换的总次数了。"


我们可以从图 2 和表 1 观察到，Windows 2000 的上下文切换开销大概为：

    1.85 usec - .046 usec = 1.8 usec

Windows XP 缩短了它的上下文切换时间，但增加了临界段的时间，每次上下文切换大约为：

    1.61 usec - .129 usec = 1.48 usec

。从 Windows 2000 到 Windows XP 的时间缩减量是一个很大的改进。Linux 上下文切换时间可以粗略估计为：

    3.56 usec - .262 usec = 3.2 usec

上面的测量表明，要选择并运行一个不同的上下文，Linux 大概比 Windows 多花一倍的时间。这个结论适用的情况是：每个线程几乎不做任何工作，只是得到 CPU 控制权后马上放弃。

这种特殊的测试不能代表很多（如果有）实际的情况。它的确清楚地显示了每种操作系统的上下文切换速度可能具有的一些局限性。我的下个专栏将加入反映实际情况的工作，用分形 CPU 周期消耗程序来测量一个或多个线程在给定时间中能够完成多少次分形计算。毕竟，如果不完成一些实际工作，上下文切换没有任何意义。

Perlvim

我相信多核系统的上下文切换时间可能非常短。因为双核实现真正意义上的并行，而不是感觉上的并行。
如果不需要共享一些资源，如内存，I/O输出设备。两个核完全可以各运行各的，互不干扰

cjaizss

Perlvim 发表于 2012-05-11 10:56
关于CPU架构的几个问题。

关于硬件栈的问题，是不是过程的定义模式，已经成为硬件架构的一部分？

栈属于硬件架构的一部分,硬件一般提供了寄存器间接寻址功能,并且也可能专门用到栈的指令.

关于cache,这个要看处理器的,处理器和处理器是不同的
上下文切换,一般还是在内存里进行,这一般是软件的支持.

linlams

Perlvim 发表于 2012-05-11 10:56
关于CPU架构的几个问题。

关于硬件栈的问题，是不是过程的定义模式，已经成为硬件架构的一部分？

-----确实有软硬件栈的，在嵌入式处理器中多有专用的硬件处理，提高效率。 如ARM，普通模式下的栈操作，与中断模式不同，会使用shadow register