1 |
On 05/01/2017 08:01 AM, Jorge Almeida wrote: |
2 |
> On Mon, May 1, 2017 at 2:46 PM, Rich Freeman <rich0@g.o> wrote: |
3 |
>> On Sun, Apr 30, 2017 at 4:17 PM, Kai Krakow <hurikhan77@×××××.com> wrote: |
4 |
>>> Am Sun, 30 Apr 2017 10:33:05 -0700 |
5 |
>>> schrieb Jorge Almeida <jjalmeida@×××××.com>: |
6 |
>>> |
7 |
>>>> It makes sense that the kernel has it. Should it be enabled? For a |
8 |
>>>> server, probably. For a single-user workstation? Maybe. |
9 |
>>> |
10 |
> |
11 |
>> |
12 |
>> Honestly, I can't think of why you wouldn't want to use it. |
13 |
>> |
14 |
>> The use cases of killing orphan processes and managing resources at a |
15 |
>> service level have already been mentioned. |
16 |
> |
17 |
> I don't usually have orphan processes (that process 1 doesn't reap). |
18 |
> My services don't require fine tuning re resources. |
19 |
> |
20 |
>> |
21 |
>> Another use case is that the kernel automatically takes cgroups into |
22 |
>> account when scheduling. So, if one of your services launches a bunch |
23 |
>> of children they'll be weighted together when allocating CPU. That |
24 |
>> means that a service with ten threads won't get 10x the CPU of a |
25 |
>> service with one thread if CPU becomes limiting, assuming equal |
26 |
>> niceness/etc. On a multi-user system the same would apply to the user |
27 |
>> running 100 processes vs 1. |
28 |
>> |
29 |
>> I also use cgroups to monitor memory use/etc at a service level. |
30 |
> |
31 |
> I don't have complex services (some might argue that very complex |
32 |
> services are badly designed services, but I leave that discussion to |
33 |
> pros). I only run single-user workstations. |
34 |
> |
35 |
>> |
36 |
>> Sure, they're somewhat optional, but they're a pretty useful kernel feature. |
37 |
> |
38 |
> No arguing there. Still, it shouldn't be pushed. It's a bad sign. |
39 |
> |
40 |
> Jorge |
41 |
> |
42 |
cgroups are not being pushed in this case. Portage threw up a warning, |
43 |
letting you know that some features of htop may not be available without |
44 |
the CONFIG_CGROUPS flag on in the kernel. htop should work to your |
45 |
liking as it is right now. Go try it out! |
46 |
|
47 |
I'm having a little trouble understanding why this particular package |
48 |
has you worried when there are dozens of others that spit out similar |
49 |
"heads up" warnings, like qemu, anything relating to graphics and |
50 |
virtualization... they're helpful messages that let you know that, if |
51 |
something doesn't work as you expect, it's probably due to something you |
52 |
have disabled. That's it. |
53 |
|
54 |
Perfect example: I use an AMD processor, but still get 'warning' |
55 |
messages about checking CONFIG_KVM_INTEL and other variables. qemu still |
56 |
works, because my kernel is built to virtualize with my CPU. Someone |
57 |
with an Intel CPU might really want that warning message, though. |
58 |
|
59 |
I've not dabbled in cgroups but they seem very useful to those who need |
60 |
to manage processes in ways the kernel itself can enforce. Cgroups |
61 |
merely help htop do its job. |
62 |
-- |
63 |
Daniel Campbell - Gentoo Developer |
64 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
65 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |