cpu亲和力总结taskset和setcpu及其他相关

分类： linux c 开发工具使用技巧 2013-09-16 11:23 3987人阅读评论(0) 收藏举报

目录(?)[+]

一：taskset -- 获取或指定进程运行的CPU.

man taskset出现
CPU affinity is a scheduler property that "bonds" a process to a given set of CPUs on the system. The Linux scheduler will honor the given CPU affinity and the process will not run on any other CPUs. Note that the Linux scheduler also supports natural CPU affinity:
翻译：
taskset设定cpu亲和力，cpu亲和力是指
CPU调度程序属性关联性是“锁定”一个进程，使他只能在一个或几个cpu线程上运行。　　对于一个给定的系统上设置的cpu。给定CPU亲和力和进程不会运行在任何其他CPU。　　注意,Linux调度器还支持自然CPU关联:（不能让这个cpu只为这一个进程服务）
这里要注意的是我们可以把某个程序限定在某一些CPU上运行，但这并不意味着该程序可以独占这些CPU，其实其他程序还是可以利用这些CPU运行。如果要精确控制CPU，taskset就略嫌不足，cpuset才是可以

-a, --all-tasks 操作所有的任务线程-p, --pid 操作已存在的pid-c, --cpu-list 通过列表显示方式设置CPU
（1）指定1和2号cpu运行25718线程的程序
taskset -cp 1,2 25718

（2），让某程序运行在指定的cpu上 taskset -c 1,2,4-7 tar jcf test.tar.gz test
（3）指定在1号CPU上后台执行指定的perl程序
taskset –c 1 nohup perl pi.pl &

二：cpuset编码测试

一个进程的CPU亲合力掩码决定了该进程将在哪个或哪几个CPU上运行.在一个多处理器系统中,设置CPU亲合力的掩码可能会获得更好的性能.一个CPU的亲合力掩码用一个cpu_set_t结构体来表示一个CPU集合,下面的几个宏分别对这个掩码集进行操作: ·CPU_ZERO() 清空一个集合 ·CPU_SET()与CPU_CLR()分别对将一个给定的CPU号加到一个集合或者从一个集合中去掉. ·CPU_ISSET()检查一个CPU号是否在这个集合中.下面两个函数就是用来设置获取线程CPU亲和力状态: ·sched_setaffinity(pid_t pid, unsigned int cpusetsize, cpu_set_t *mask) 该函数设置进程为pid的这个进程,让它运行在mask所设定的CPU上.如果pid的值为0,则表示指定的是当前进程,使当前进程运行在mask所设定的那些CPU上.第二个参数cpusetsize是mask所指定的数的长度.通常设定为sizeof(cpu_set_t).如果当前pid所指定的进程此时没有运行在mask所指定的任意一个CPU上,则该指定的进程会从其它CPU上迁移到mask的指定的一个CPU上运行. ·sched_getaffinity(pid_t pid, unsigned int cpusetsize, cpu_set_t *mask) 该函数获得pid所指示的进程的CPU位掩码,并将该掩码返回到mask所指向的结构中.即获得指定pid当前可以运行在哪些CPU上.同样,如果pid的值为0.也表示的是当前进程.

[html] view plaincopy

cpu_set_t的定义
# define __CPU_SETSIZE 1024
# define __NCPUBITS (8 * sizeof (__cpu_mask))
typedef unsigned long int __cpu_mask;
# define __CPUELT(cpu) ((cpu) / __NCPUBITS)
# define __CPUMASK(cpu) ((__cpu_mask) 1 << ((cpu) % __NCPUBITS))
typedef struct
{
__cpu_mask __bits[__CPU_SETSIZE / __NCPUBITS];
} cpu_set_t;
# define __CPU_ZERO(cpusetp) \
do { \
unsigned int __i; \
cpu_set_t *__arr = (cpusetp); \
for (__i = 0; __i < sizeof (cpu_set_t) / sizeof (__cpu_mask); ++__i) \
__arr->__bits[__i] = 0; \
} while (0)
# define __CPU_SET(cpu, cpusetp) \
((cpusetp)->__bits[__CPUELT (cpu)] |= __CPUMASK (cpu))
# define __CPU_CLR(cpu, cpusetp) \
((cpusetp)->__bits[__CPUELT (cpu)] &= ~__CPUMASK (cpu))
# define __CPU_ISSET(cpu, cpusetp) \
(((cpusetp)->__bits[__CPUELT (cpu)] & __CPUMASK (cpu)) != 0)

上面几个宏与函数的具体用法:

[html] view plaincopy

cpu.c
#include<stdlib.h>
#include<stdio.h>
#include<sys/types.h>
#include<sys/sysinfo.h>
#include<unistd.h>
#define __USE_GNU
#include<sched.h>
#include<ctype.h>
#include<string.h>
int main(int argc, char* argv[])
{
int num = sysconf(_SC_NPROCESSORS_CONF);
int created_thread = 0;
int myid;
int i;
int j = 0;
cpu_set_t mask;
cpu_set_t get;
if (argc != 2)
{
printf("usage : ./cpu num\n");
exit(1);
}
myid = atoi(argv[1]);
printf("system has %i processor(s). \n", num);
CPU_ZERO(&mask);
CPU_SET(myid, &mask);
if (sched_setaffinity(0, sizeof(mask), &mask) == -1)
{
printf("warning: could not set CPU affinity, continuing...\n");
}
while (1)
{
CPU_ZERO(&get);
if (sched_getaffinity(0, sizeof(get), &get) == -1)
{
printf("warning: cound not get cpu affinity, continuing...\n");
}
for (i = 0; i < num; i++)
{
if (CPU_ISSET(i, &get))
{
printf("this process %d is running processor : %d\n",getpid(), i);
}
}
}
return 0;
}

下面是在两个终端分别执行了./cpu 0 ./cpu 2 后得到的结果. 效果比较明显.

QUOTE:

Cpu0 : 5.3%us, 5.3%sy, 0.0%ni, 87.4%id, 0.0%wa, 0.0%hi, 2.0%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 5.0%us, 12.2%sy, 0.0%ni, 82.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

在我的机器上sizeof(cpu_set_t)的大小为128,即一共有1024位.第一位代表一个CPU号.某一位为1则表示某进程可以运行在该位所代表的cpu上.

例如CPU_SET(1, &mask);

则mask所对应的第2位被设置为1.
此时如果printf("%d\n", mask.__bits[0]);就打印出2.表示第2位被置为1了.
具体我是参考man sched_setaffinity文档中的函数的.
然后再参考了一下IBM的 developerWorks上的一个讲解.

三：，使用nice和renice设置程序执行的优先级

格式：nice [-n 数值] 命令nice 指令可以改变程序执行的优先权等级。指令让使用者在执行程序时，指定一个优先等级，称之为 nice 值。这个数值从最高优先级的-20到最低优先级的19。负数值只有 root 才有权力使。一般使用者，也可使用 nice 指令來做执行程序的优先级管理，但只能将nice值越调越高。可以通过二种方式来给某个程序设定nice值：
1，开始执行程序时给定一个nice值，用nice命令 2，调整某个运行中程序的PID的nice值，用renice命令通常通过调高nice值来备份，为的是不占用非常多的系统资源。例：
nice -n 10 tar zcf test.tar.gz test
由nice启动的程序，其子进程会继承父进程的nice值。查看nice值
# nice -n -6 vim test.txt &
# ps -l F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
4 S 0 19427 2637 0 75 0 – 16551 wait pts/6 00:00:00 bash
4 T 0 21654 19427 0 71 -6 – 23464 finish pts/6 00:00:00
vimrenice调整运行中程序的nice值格式：renice [nice值] PID

四，使用ulimit限制cpu占用时间

注意，ulimit 限制的是当前shell进程以及其派生的子进程。因此可以在脚本中调用ulimit来限制cpu使用时间。例如，限制tar的cpu占用时间，单位秒。
# cat limit_cpu.sh ulimit -SHt 100 tar test.tar.gz test如果tar占用时间超过了100秒，tar将会退出，这可能会导致打包不完全，因此不推荐使用ulimit对cpu占用时间进行限制。另外，通过修改系统的/etc/security/limits配置文件，可以针对用户进行限制。

五。使用程序自带的对cpu使用调整的功能

某些程序自带了对cpu使用调整的功能，比如nginx服务器，通过其配置文件，可以为工作进程指定cpu，如下：
worker_processes 3;
worker_cpu_affinity 0001 0010 0100 1000;
这里0001 0010 0100 1000是掩码，分别代表第1、2、3、4颗cpu核心，这就使得cpu的使用比较平均到每个核心上。

[html] view plaincopy

六：查看cpu状态

1，可以使用mpstat指令，UNIX系统下，mpstat有相当完备的选项可供使用，而在笔者的REDHAT AS5中，mpstat只有区区-P选项。以下是笔者运行mpstat –P ALL的截图，可以看到各个CPU的运行情况。
[kxu@nothung MovieInfo]$ mpstat -P ALL
Linux 2.6.18-8.el5 (nothung.localdomain) 02/03/2008
10:50:43 PM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
10:50:43 PM all 32.82 0.00 4.73 0.10 0.00 0.13 0.00 62.22 1035.82
10:50:43 PM 0 26.73 0.00 3.96 0.08 0.00 0.13 0.00 69.08 141.13

2，top，然后输入“1”，查看cpu状态输入大写“H”，查看程序的线程信息

七：写高并发量程序是需要注意问题

系统调用是许多开发人员经常忽视的障碍。影响可扩展性的 2 种最常见的意外调用是 malloc 和 gettimeofday。malloc 调用会遇到它里面的锁，它可序列化调用者和执行。如果线程分配 1 个大型内存块，然后运行较长时间，那么该费用就没那么急需。使用更高效的内存分配器，顺畅运行多次调用 malloc 的应用。英特尔线程构建模块包括可为该目的而极致扩展的内存分配调用。其它可用的第三方内存分配库也可比 malloc 表现出色。在第二个示例中，当 200 多条线程同时调用 gettimeofday，它也可能像顺序区域一样运行。只有一条线程调用 gettimeofday。使用本地计时器在线程内计时。可通过配置使 gettimeofday 调用恢复本地内核计数器或全局处理器计数器，该技巧假设它正利用全局处理器而非本地内核 tsc 计数器。考虑其它可能成为障碍的系统调用和库，使用替代选项或尽可能不使用它们。

cpu缓存相关网站介绍

http://software.intel.com/zh-cn/articles/optimization-and-performance-tuning-for-intel-xeon-phi-coprocessors-part-1-optimization

http://www.cnblogs.com/yanlingyin/archive/2012/02/15/thinkingincache.html