在 linux 上使用更多线程的进程会比使用一个线程的进程有更多的 CPU 时间吗? [英] Would process with more threads on linux have more cpu time than process with one thread?

查看:45
本文介绍了在 linux 上使用更多线程的进程会比使用一个线程的进程有更多的 CPU 时间吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Linux 上有更多线程的进程会比只有一个线程的进程有更多的 CPU 时间吗?

Would a process with more threads on Linux have more cpu time than a process with one thread?

在 Linux 中进程和线程由任务结构描述,而调度是基于任务.我还发现了这个:

In Linux processes and threads are described by a task struct, and scheduling is based on tasks. I found also this:

当一个新进程被创建时,do_fork() 以如下方式设置当前(父)进程和 p(子)进程的计数器字段:

When a new process is created, do_fork() sets the counter field of both current (the parent) and p (the child) processes in the following way:

current->counter >>= 1;
p->counter = current->counter;

换句话说,留给父级的刻度数被分成两半,一份给父级,一份给子级.这样做是为了防止用户使用以下方法获得无限量的CPU时间:父进程创建一个运行相同代码的子进程,然后杀死自己;通过适当调整创建速率,子进程将始终在其父进程的量程到期之前获得新的量程.这个编程技巧不起作用,因为内核不奖励分叉.类似地,用户不能通过在 shell 中启动大量后台进程或通过在图形桌面上打开大量窗口来占用处理器的不公平份额.更一般地说,一个进程不能通过分叉多个后代来占用资源(除非它有权限给自己一个实时策略).

In other words, the number of ticks left to the parent is split in two halves, one for the parent and one for the child. This is done to prevent users from getting an unlimited amount of CPU time by using the following method: the parent process creates a child process that runs the same code and then kills itself; by properly adjusting the creation rate, the child process would always get a fresh quantum before the quantum of its parent expires. This programming trick does not work since the kernel does not reward forks. Similarly, a user cannot hog an unfair share of the processor by starting lots of background processes in a shell or by opening a lot of windows on a graphical desktop. More generally speaking, a process cannot hog resources (unless it has privileges to give itself a real-time policy) by forking multiple descendants.

其实我在内核源码里没有找到,不过可能是我的错,可能是我看错了内核版本.

Actually I didn't find that in the kernel sources, but maybe it's my fault, maybe I saw wrong kernel version.

但是后来发生了什么,每个线程会像一个单独的进程一样参与调度吗?一个有十个线程的进程会比一个有一个线程的进程得到十倍的滴答声吗?从这个意义上说,IO 怎么样?

But what happens later, would every thread participate in scheduling like a separate process? Would a process with ten threads get ten times more ticks than a process with one thread? What about IO in this sense?

推荐答案

是的,具有更多线程的进程将比其竞争对手获得更多的 CPU 时间.一个众所周知的案例是 maven 编译,maven 使用大量 CPU 密集型线程,占用系统.

Yes, a process with more threads would get more CPU time than its competitors. A well-known case would be a maven compile, maven uses lots of CPU-intensive threads, hogging the system.

但是,当前的 linux 调度程序不仅仅考虑任务,它还考虑了 cpu cgroup 层次结构中的控制组.因此,CPU时间在控制组之间分配,然后在每个控制组中,CPU时间在任务之间分配.

But, the current linux scheduler doesn't take only tasks into account, it also takes control groups in the cpu cgroup hierarchy into account. So, CPU time is divided between control groups, and then in each control group, CPU time is divided between tasks.

自 2.6.38 起,Linux 会根据会话 ID 自动将 taks 放入不同的 cpu cgroup.这意味着例如: konsole/gnome-terminal 中的单独选项卡有自己的控制组.所以现在你的 maven 编译被很好地隔离了,不再占用系统.请参阅 kernelnewbieslwn.net.

Since 2.6.38, Linux automatically puts taks into different cpu cgroups based on their session ids. This means that e.g: separate tabs in konsole/gnome-terminal get their own control group. So now your maven compilation is nicely isolated, and no longer hogs the system. See the descriptions at kernelnewbies and lwn.net.

在 2.6.38 出现在大多数系统之前,Lennart Poettering 在 this 上展示了如何在 shell 脚本上手动执行此操作LKML 消息.

Before 2.6.38 hit most systems, Lennart Poettering showed how to do it manually on a shell script at this LKML message.

我实际上有一个运行 Eclipse 和 maven 编译的系统,以及从 2.6.38 之前到 2.6.38 之前的更改 + Lennart 的 cgroup 绑定(我放在 /etc/bashrc 在我的 Eclipse 启动器脚本中)非常完美.Maven 不再占用系统(如果不是 CPU 负载监视器,你不会知道有一个 Maven 编译正在进行),而 Eclipse 现在只占用自己,而不是系统的其余部分(我会满足于Eclipse).现在我只需要将内核更新为具有更好脏页写回的内核,并且该系统将轻而易举地工作.

I actually have a system where I run Eclipse and maven compiles, and the change from pre-2.6.38 to pre-2.6.38 + Lennart's cgroup binding (which I put on /etc/bashrc and on my Eclipse launcher script) was just perfect. Maven no longer hogs the system (you wouldn't know there was a maven compile going on if it weren't for the CPU load monitor), and Eclipse now just hogs itself, not the rest of the system (I'll settle for that with Eclipse). Now I just need to update the kernel to one with better dirty-page writeback and that system will be a breeze to work on.

这篇关于在 linux 上使用更多线程的进程会比使用一个线程的进程有更多的 CPU 时间吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆