问题描述
在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:
current->counter >>= 1;
p->counter = current->counter;
换句话说，留给父母的壁虱数被分成两半，一个为父母，一个为孩子.这样做是为了防止用户使用以下方法获得无限的CPU时间:父进程创建运行相同代码的子进程，然后杀死自己；通过适当地调整创建速率，子进程将始终在其父级的量子过期之前获得一个新的量子.该编程技巧不起作用，因为内核不奖励分叉.同样，用户不能通过在外壳中启动许多后台进程或在图形桌面上打开许多窗口来浪费处理器的不公平份额.一般来说，一个进程无法通过派生多个后代来占用资源(除非它具有向其提供实时策略的特权).
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编译已经很好地隔离了，不再占用系统了.请参阅 kernelnewbies 和 lwn.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 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.338之前的版本更改为2.6.338之前的版本+ 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时间?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！