Also the framework uses (some would say abuses) cgroups is major ways to
control scheduling -- there is a cgroup for processes it considers to be in
the "background", and threads in that cgroup can only get around 10% of the
CPU all together. That is, foreground processes can never lose more than
Thanks.
So, is there a way that I can estimate the execution time of a ready-
to-go thread, even in the worst case?
On 12月8日, 上午8时59分, Brad Davis wrote:
> Yes and no. If all the processes were active and runnable (not
> blocked waiting for something else to happen) then yes, you would be
> shari
Linux kernel could be more complicated when evaluating priorities and
defining "runnable" processes. While "nice" values only impact the
base/static priorities of the process, these may not be the actual
priorities, "dynamic priorities" as defined and used by scheduler. Further
the class of schedu
Yes and no. If all the processes were active and runnable (not
blocked waiting for something else to happen) then yes, you would be
sharing the CPU with all of them. However, most of them are blocked
for one reason or another (disk read, message, signal, UI interaction,
another process, ...).
On
