linux – 有多少个Context Switch是“正常的”(作为CPU核心(或其他)的函数)？

系统调用

系统调用会导致上下文切换本身的性质.当一个进程进行系统调用时,它基本上会告诉内核从它当前的时间点和内存中接管进行该进程无权执行的操作,并在完成时返回到同一位置.

当我们从Linux查看write(2)系统调用的定义时,这变得非常清楚：

NAME
       write - write to a file descriptor

SYNOPSIS
       #include 

       ssize_t write(int fd,const void *buf,size_t count);

DESCRIPTION
       write() writes up to count bytes from the buffer pointed buf to the file
       referred to by the file descriptor fd. [..]

RETURN VALUE
       On success,the  number of bytes written is returned (zero inDicates
       nothing was written). On error,-1 is returned,and errno is set
       appropriately.
       [..]

这基本上告诉内核从进程中接管操作,向上移动到count字节,从* buf指向的内存地址开始到当前进程的文件描述符fd,然后返回到进程并告诉他它是如何进行的.

显示这一点的一个很好的例子是基于Valve source的游戏的专用游戏服务器,hlds.http://nopaste.narf.at/f1b22dbc9显示由一个没有玩家的游戏服务器的单个实例完成的一秒钟系统调用.这个过程在Xeon X3220(2.4Ghz)上占用大约3％的cpu时间,只是为了让您感觉这是多么昂贵.

多任务

上下文切换的另一个来源可能是不进行系统调用但需要从给定的cpu移出以为其他进程腾出空间的进程.

可视化这个的一个很好的方法是cpuburn. cpuburn本身不做任何系统调用,它只是迭代它自己的内存,所以它不应该导致任何上下文切换.

获取空闲机器,启动vmstat,然后为系统的每个cpu核心运行burnMMX(或cpuburn包中的任何不同测试).到那时你应该有完整的系统利用率,但几乎没有增加任何上下文切换然后尝试启动更多进程.随着流程开始与cpu核心竞争,您将看到上下文切换速率增加.切换量取决于进程/核心比率和内核的多任务分辨率.

进一步阅读

linfo.org对于@L_607_41@和system calls有一个很好的写作. Wikipedia有关于系统调用的通用信息和一个很好的链接集合.